[BUG] Tiddlers with multi-line fields can be incorrectly exported as .tid files

[saqimtiaz]

Describe the bug
Create a tiddler with a multi-line field. Export it using the tiddler toolbar. Exporting as .tid is enabled but the exported file cannot be correctly imported on another TiddlyWiki

To Reproduce

1. Enter the following in a tiddler on tiddlywiki.com and click the resulting button:

<$button>create "test" tiddler
<$action-setfield $tiddler="test" text="This is some text" otherfield={{HelloThere}}/>
</$button>

2. Navigate to the "test" tiddler and export it as a .tid file
3. Import the resultant file to another TiddlyWiki file.

We probably need a filter operator that checks for unsafe fields and accordingly disables the .tid export option. Or alternatively a filter operator that given an input title, returns the supported export formats.

Also see #5708 (comment). With the introduction of the JSON format store area and greater freedom in field names, the same issue will need to be addressed when tiddler field names contain a : character.

[pmario]

Also see #5708 (comment). With the introduction of the JSON format store area and greater freedom in field names, the same issue will need to be addressed when tiddler field names contain a : character.

That's true. ... At "How could system-fields look like with 5.2.x" #5805 .. I did suggest a possible multiline .tid format like so:

title: my tiddler
#:/user/multiline/teaser: rows="4" minHeight="3em"
tags: a b c 
teaser: -=-=-=-=-                         <- end-marker configuration for the parser
line 1
line 2
line 3
-=-=-=-=-                                 <- end-marker
some text

This format contains both "edge-cases" you discuss here. ... The proposed system-field contains 2 : chars. Where the second one is the "splitter"

And it contains a "theoretical" multi line field. ... Where I personally would like the "marker" to be dynamic.

In the example above the teaser field is depending on the existence of the system-field, which tells the core, that the teaser is a multiline field.

I'm not 100% sure, how the .tid parser / regexp looks atm. .. But we will probably make it line based. So the information from the system-field needs to be known by the parser, when it scans the teaser field

just some thoughts

[saqimtiaz]

@pmario It would be prudent not to conflate the two issues. This is a relatively easy fix that can be accomplished during the course of the work on #5708

Changing the .tid format will have backwards compatibility considerations and any discussion around a new format needs to be a considered and careful one that amongst other things also takes into account existing formats that we might be able to leverage.

[pmario]

Changing the .tid format will have backwards compatibility considerations ...

IMO the new fields in general will never be backwards compatible. In 5.1.23 only "lowercase letters, digits and the characters underscore (_), hyphen (-) and period (.)" are allowed. This is also true for the .tid format.

So the only thing which I think is important, is "forward compatibility" to allow a seamless transition from 5.1.x to 5.2.x

As it seems now the only character that is problematic in .tid-fields is :

From my point of view: #/asdf/aaa: {"some JSON stuff"} would be perfectly fine, but is in no way backwards compatible.