Tiddlywiki5: Show raw text (instead of wikified) of system tiddlers

[Jermolene]

Viewing many shadow system tiddlers doesn't display anything useful, and in some cases causes a recursion error. This is confusing for beginners, who are apt to think that things are their fault.

It is proposed to display system tiddlers in raw text (with appropriate highlighting) except for:

• System tiddlers whose title contains a single slash (eg $:/ControlPanel, $:/Import, $:/AdvancedSearch)
• System tiddlers with the tag $:/tags/Image (eg $:/core/images/help, $:/core/images/palette)

All other system tiddlers would be wikified in the usual way.

This is quite a substantial change to the TiddlyWiki UI. I've become convinced that it's worth fixing the problem because I've seen so many users confused by it. But we are going to have to check things very carefully to ensure that there are no unexpected consequences.

This is a refinement of an earlier proposal #919.

[twMat]

It is proposed to display system tiddlers in raw text (with appropriate highlighting) except for:

System tiddlers whose title contains a single slash (eg $:/ControlPanel, $:/Import, $:/AdvancedSearch)
System tiddlers with the tag $:/tags/Image (eg $:/core/images/help, $:/core/images/palette)

I agree with the identified problem but the above solution/rules seem very special. As you point out, it deviates from a UI point but also:

The solution is not easily applied by plugin authors. Plugins almost always have multiple slashes single slashes. So either the plugin author has to adapt the plugin around the supposedly supporting solution (which is backward)... or the rule can't be used and end users are still stuck with the original problems.

And... what if I want a single slash system tiddler to render like normal? That is a very likely situation! Again, I'd have to adapt the tiddler because of the rule. (meh!)

There's also a bit of a contradiction; a stated main reason was to save users from being confused by some tiddlers causing unexpected behaviours. But with the proposed UI changes it will again not be possible to understand why some tiddlers behave differently.

Proposal

919 argues that introducing a system tag would be inappropriate (even if I don't quite understand the argument). So, may I instead propose to use a hidden field, e.g output:rawtext. This is not invisible as the above proposal but it is still not visible to distract or draw attention to it.

Plus, treating this as a manipulable parameter could open for a more general output specification based on other existing output formats / content types. If there's a reason why one would want to preview output formats in edit mode... I'm guessing there could be some reason why one would want such output too.

[Jermolene]

This is a simple change, so I'm going to back it out for 5.1.14 and we can revisit it later.

For the record, the requisite changes to $:/core/ui/ViewTemplate/body are:

title: $:/core/ui/ViewTemplate/body
tags: $:/tags/ViewTemplate

\define re() ^\$\:\/([^/])*$

<$reveal tag="div" class="tc-tiddler-body" type="nomatch" state=<<folded-state>> text="hide" retain="yes" animate="yes">

<$list filter="[all[current]is[missing]!is[shadow]]" template="$:/language/MissingTiddler/Hint" emptyMessage="""

<$list filter="[all[current]!is[system]] [all[current]tag[$:/tags/Image]] [all[current]regexp<re>] +[!has[plugin-type]!field:hide-body[yes]]">

<$transclude/>

</$list>

<$list filter="[all[current]is[system]] -[all[current]tag[$:/tags/Image]] -[all[current]regexp<re>] +[!has[plugin-type]!field:hide-body[yes]]">

<$codeblock code={{!!text}} language={{!!type}}/>

</$list>

"""/>

</$reveal>

[pmario]

Proposal
... So, may I instead propose to use a hidden field, e.g output:rawtext. This is not invisible as the above proposal but it is still not visible to distract or draw attention to it.

Plus, treating this as a manipulable parameter could open for a more general output specification based on other existing output formats / content types. If there's a reason why one would want to preview output formats in edit mode... I'm guessing there could be some reason why one would want such output too.

It think, that's going in the right direction. ...

With TiddlySpace, we had a similar problem, that the "display-type" can be different to the "content-type". eg: An SVG most of the time should be shown as an image image/svg+xml. But sometimes it should be shown as text/plain, depending on the authors needs.

There have to be 2 different settings, as Mat suggests, because if single tiddlers are served by servers, they either use the file extension, or other meta data to specify the mime-type of the resource, that should be served. ... So the TW conent-type field has to be a valid mime-type, that standard servers and browsers, are able to understand. ...

The TW rendering process is different here, because we also want to specify an authors "intention". eg:

• "System tiddlers should be shown in text/plain, to make is simpler for new users"
  
  
  
  • "BUT some System tiddlers should be excluded from this rule .. for plugin authors"
  
  
  • and so on ....
  
  
• More generally speaking: Authors may want to specify a "rendering-type".

I'm not sure .. yet, how we should implement it. But I'm pretty sure we should use some sort of existing spec. eg: mime-types ... to achieve the goal

[danielo515]

This has been closed because it has been implemented with the current description ? What about the plugins that depend on this ? What about all the problems that has been exposed here ?

[Jermolene]

@danielo515 I've re-merged the change to help the discussion along.

Do you know of plugins that depend on being able to wikify system tiddlers with more than one slash in the title?

What about all the problems that has been exposed here ?

We've got a serious problem with TW5 whereby casually opening certain system tiddlers can crash the system. It's pretty bad; it discourages experimentation, and makes people think that they've made a mistake themselves.

I've yet to get the feedback I was hoping for, which is to understand which existing plugins or editions depend on the behaviour that is being changed.

[danielo515]

@jermolene I understand the lot8vdti behind this change.

I can't think of any plugin breaking because this change, but there should be some . However making this a main feature is read of a pre-release one sounds very risky. Many people will get the last version and maybe their favourite plugin will stop working. Surely all of them will get confused or anger, but just a few will report back the problem.

Once tw reached the stable version you were much more resilient to make breaking changes . However this has changed recently. Or that is my preception

[Jermolene]

Hi @danielo515

However making this a main feature is read of a pre-release one sounds very risky

Just to be clear, the change is in the 5.1.15-prerelease, and not in the current release.

Once tw reached the stable version you were much more resilient to make breaking changes . However this has changed recently. Or that is my preception

The first issue here is to establish whether this is in fact a breaking change, and if it is, what can be done to mitigate.

You're right that the default position is to avoid breaking changes, but the overall decision depends on an analysis of the benefits. (One could imagine a security issue that could only be addressed by a breaking change).

I'd emphasise again that in this case the problem I am trying to address is serious and insidious.

[danielo515]

Just to be clear, the change is in the 5.1.15-prerelease, and not in the current release.

Oook, that makes things clearer. I though it was part of official 5.1.14

I am not against making breaking changes, in fact I think it is necessary or we will end like browsers nowadays. However, I think it is necessary to make it in phases. If this is not part of 5.1.14 then I am right with it.

Regards

[Evolena]

As documentation, examples for plugins (like $:/plugins/tiddlywiki/railroad/example) won't work anymore when directly opened, this change forces users to view them through the ControlPanel. Not really breaking, but it can be quite annoying.

Maybe the multiple-slash rule could be enforced only if the system tiddler does not have type=text/vnd.tiddlywiki. Would this be satisfying?
Currently on prerelease, this concern 5 shadow system tiddlers (excluding the 3 that already match the single-slash rule):

[all[shadows]is[system]type[text/vnd.tiddlywiki]]
$:/Acknowledgements
$:/language/Modals/Download
$:/language/Modals/SaveInstructions
$:/SiteTitle
$:/core/templates/static.content
$:/DefaultTiddlers
$:/core/macros/timeline
$:/core/wiki/title

[Jermolene]

Hi @Evolena thanks for the suggestion. I've just merged @rubaboo's PR with the fix, along with a followup commit b99a1b64967f223c5c2abf70fa2aa04766addcb6 to remove unneeded text/vnd.tiddlywiki settings from some core system tiddlers, and 7436fc7374478de34f25abbd549d80436ac6e303 to add them to shadow system tiddlers like $:/plugins/tiddlywiki/railroad/example).