tiddler format for multiline fields (esp. node.js)

[tobibeer]

Original title: Field values containing line breaks don't work under node.js

https://github.com/Jermolene/TiddlyWiki5/issues/1932#issuecomment-141637499:

fields containing newlines don't get saved properly under Node.js (the reason is that the .tid file format can only cope with newlines in the text field). It can be fixed by switching to JSON tiddlers as required.

[Jermolene]

This is a problem with the filesystem adaptor plugin. The options include:

• Default to using JSON format for tiddler files
• Automatically detect attempts to save a tiddler with fields containing line breaks, and switch to saving in JSON format instead
• Devise an extended .tid file format that is backwards compatible with the current format but allows line breaks within fields
• Devise a new (incompatible) tiddler file format that is as easy to type as the existing format but that allows line breaks within fields
• Adopt another standard file format (eg YAML)

[tobibeer]

1. default to using JSON format for tiddler files
   • => very bad for plain-text-editing
2. automatically switch to saving in JSON format instead
   • => ok, but still bad for plain-text-editing, especially if one heavily depended on multi-line fields
3. extended .tid file format (backwards compatible)
   • => anyone can invent that => big medal
4. new (incompatible) tiddler file format allowing line breaks within fields
   • => perhaps the most sensible approach
5. adopt another standard file format (eg YAML)
   • => would consider this an option only if better than 4.

Perhaps an idea for 4.:

title: foo
tags: bar baz
created: 20150919130000
multi-line:+
!mumble
*frotz
**gronk
text:+

the tiddler's body

The text field being treated as any other multi-line field and having to be specifically declared. This could perhaps even remain .tid format with auto-detection for lines...

1. starting with a valid field-name
2. followed by a colon
3. followed by + being the last character in the line

...hence treating the next lines as a multi-line field-value.

[Jermolene]

...hence treating the next lines as a multi-line field-value.

What is the terminator? Anything that looks like another field definition? I think we need explicit closing of multiline fields.

How about treating the first character of the line as special, and then:

• +field:<terminator> to introduce a multiline field
• <terminator> to end a multiline field

For example:

title: My Tiddler
+longfield:.
This is the long
field

value
.
another-field: single line value

This is the text field

Which can also contain line breaks

We could also introduce a better syntax for lists by using > to indicate a list, with the same convention for indicating the end of the list. In this example, the empty string is used as a terminator, which would be quite handy for lists:

title: $:/tags/ViewTemplate
>list:
[[$:/core/ui/ViewTemplate/title]]
[[$:/core/ui/ViewTemplate/unfold]]
[[$:/core/ui/ViewTemplate/subtitle]]
[[$:/core/ui/ViewTemplate/tags]]
[[$:/core/ui/ViewTemplate/classic]]
[[$:/core/ui/ViewTemplate/body]]

description: Another single line field

Anyhow, I guess that suggestion could in fact be compatible with the existing format.

[tobibeer]

What is the terminator? Anything that looks like another field definition? I think we need explicit closing of multiline fields.

You're right. The terminator could be any character that would usually not be of use on its own on a newline at the end. Can be a dot . or a minus - or another +.

title: foo
tags: bar baz
created: 20150919130000
multi-line:+
!mumble
*frotz
**gronk
+
text:+

the body

What would be the benefit of a special starting symbol?

[Jermolene]

What would be the benefit of a special starting symbol?

So that we can distinguish whether multi-line:+ is a field with the value "+" or the start of a multiline field.

As for lists, I would simply use the same syntax as multi-line fields, not another one. At least, I don't quite see how the distinction pf being an explicit list in plain-text-format would be relevant.

The idea would be that the items in the list would be automatically bracketed if required. So,

My Tiddler
Another Tiddler

would come through as [[My Tiddler]] [[Another Tiddler]].

[tobibeer]

So that we can distinguish whether multi-line:+ is a field with the value "+" or the start of a multiline field.

I think that would be a matter of specification that multi-line fields do end in :+ so long as there are no spaces between : and + as well as no characters that follow. One could still have + as a field value like so...

some-field-containing-plus: +

...which is how things are stored today anyway.

But yes, just typing plain text one might forget that convention and wonder why typing...

field:+

...would eat up the following fields including the tiddler text. But then, the conventions for tid-files are really just a few, so I think it is safe to assume that people who actually do plain text editing can remember that rule.

[tobibeer]

As for lists, I would simply use the same syntax as multi-line fields, not another one. At least, I don't quite see how the distinction of being an explicit list in plain-text-format would be relevant. Within the wiki itself there needs to be another way, anyway, to declare a field as being a list-field (or tag-field). Not?

But yes, it might improve readability to actually save lists and also tags as multiline fields.

[Jermolene]

@tobibeer the problem with your suggestion is that it breaks backwards compatibility; there's no getting away from the fact that field:+ is valid in current .tid files.

As to lists (which includes tags), the distinction is that list items need quotes. The point of the multiline list format is to avoid having to type the double square brackets quotes.

[tobibeer]

The point of the multiline list format is to avoid having to type the double square brackets quotes.

That I understand and welcome. I believe, with an explicit multi-line format and it being used for what TiddlyWiki identifies as list-fields, leaving out double square brackets could be considered implicit, hence optional... in the way such a list-field gets interpreted when loaded.

What I mean is, the core knows from somewhere else that something is a list field without that needing to be an explicit part of the tid-file markup.

So, when one uses multi-line format for a list-field, every line can be considered a list entry by default.

there's no getting away from the fact that field:+ is valid in current .tid files

That I was aware of, hence my putting the proposal under 4. above.

[Jermolene]

I believe, with an explicit multi-line format and it being used for what TiddlyWiki identifies as list-fields

The file format needs to be interpreted unambiguously, independently of the settings of the wiki that is importing the content. Bear in mind that we'll want to use this file format for other purposes than just importing.

leaving out double square brackets could be considered implicit, hence optional... in the way such a list-field gets interpreted when loaded.

They're not being left out so much as replaced with using a line break to delineate entries.

[tobibeer]

The file format needs to be interpreted unambiguously, independently of the settings of the wiki that is importing the content.

Mhhh, but there is no tiddler-based definition / format for what constitutes a list field, not at the moment there isn't. Only TiddlyWiki and its conventions know of that.

It sure has its benefits to be more explicit about that even in the tid format. But then, would there be the case where for one tiddler field "foo" is a list field and for another it ain't? That sounds rather inconsistent. So, the definition of how to interpret a tiddler correctly lies not necessarily in the tidder.

For example, for a TiddlyWiki to do anything meaningful with a tmap field, it obviously needs to know about TiddlyMap... same for knowing what is to be interpreted as a list-field and what isn't.

They're not being left out so much as replaced with using a line break to delineate entries.

While redundant, not sure if the format should accept double square brackets nonetheless, or quotes.

[pmario]

If there should be a new format I'd vote for YAML +1

YAML is human readable, well know, battle tested with support and a hell lot of js libraries. Support at stackoverflow and and and ...

[Jermolene]

@tobibeer there is no ambiguity. A multi-line list field would end up as a space delimited list of double square bracket quoted tiddler titles, just like the tags and list fields. So it's still just a shortcut for the existing format. The behaviour is the same as putting my-list-field: one two three in an existing .tid file; everything works fine if one later uses the list filter operator to read the list.

While redundant, not sure if the format should accept double square brackets nonetheless, or quotes.

Not really. The proposed new format defines an alternative to using double square brackets; the two ways of delimiting the list are really mutually exclusive.

[t5a]

Please forgive me if this has already been discussed, but what about \n which shadows use or
?

On Sat, Sep 19, 2015 at 12:49 PM, Jeremy Ruston notifications@github.com wrote:

@tobibeer https://github.com/tobibeer there is no ambiguity. A multi-line list field would end up as a space delimited list of double square bracket quoted tiddler titles, just like the tags and list fields. So it's still just a shortcut for the existing format. The behaviour is the same as putting my-list-field: one two three in an existing .tid file; everything works fine if one later uses the list filter operator to read the list.

While redundant, not sure if the format should accept double square brackets nonetheless, or quotes.

Not really. The proposed new format defines an alternative to using double square brackets; the two ways of delimiting the list are really mutually exclusive.

— Reply to this email directly or view it on GitHub https://github.com/Jermolene/TiddlyWiki5/issues/1947#issuecomment-141701599 .

[Jermolene]

Hi @Infurnoape I'm afraid the trouble is that that wouldn't be backwards compatible, but it would be fine for a new file format.

[tobibeer]

It would also not be very pretty to edit, hence maintainable when working in the text file... which I think should be a core premise for designing a new format.

[felixhayashi]

Thanks @tobibeer for creating this issue. I think TW would critically benefit from multiline fields. At the moment, the situation is confusing as multiline is allowed in html mode but creates conflicts in nodejs mode (https://github.com/Jermolene/TiddlyWiki5/issues/1932#issuecomment-141637499, #1955).

How about treating the first character of the line as special, and then: +field: to introduce a multiline field

to end a multiline field

@Jermolene This really sounds like a solution similar to the "heredoc" notation, which is often used in bash, php and other programming languages:

• https://en.wikipedia.org/wiki/Here_document
• https://en.wikipedia.org/wiki/Here_document#Multiline_string_literals
• http://php.net/manual/en/language.types.string.php#language.types.string.syntax.heredoc

But when does a field become multiline? Put otherwise, when is a field assigned a + (or marked otherwise) in the tid file and who is responsible for this? If tje user is responsible for this, what if he/she forgets to mark a field as multiline, does #1955 happen in nodejs? Also, Where is the sense of marking a field as multiline, shouldn't all fields not ideally simply accept multiline without breaking (just like HTML attributes accept newlines)? So shouldn't we have a robust format that works all the time?

While I think the simplicity of the current .tid file format is beautiful, not being able to add multiline is a major drawback and maybe instead of hacking the current format, a new format would make sense?

If there should be a new format I'd vote for YAML +1

@pmario I was about to vote for an XML solution. Something like:

<tiddler title="XYZ" created="…"  modified="…"  type="text/vnd.tiddlywiki">
<text>Bla</text>
<field1>Blub</field1>
<tags>[[A]] [[B]]</tags>
<list>
  [[C]]
  [[D]]
</list>
</div>

Some essential fields could be modelled as attributes (e.g. type, the rest are modelled as elements e.g. tags, list)

But I also like YAML, have worked a lot with it. However, YAML is not as robust and flexible as XML as it depends on indentation. The big advantage of course is readability and less code.

[tobibeer]

@pmario / @Jermolene... I find it difficult to imagine a YAML format supporting multiline fields ...compared to the indeed rather intuitive XML alternative proposed by @felixhayashi. Could either of you doodle a simple draft for what that could / would actually look like?

As for xml, a hunch has me think I'd prefer a version that doesn't involve it.

I think I'd still favor a slightly modified, human readable and, most importantly, editable .tid format supporting multi-line fields, e.g. perhaps called .tidm or .tidx files.

[Jermolene]

But when does a field become multiline? Put otherwise, when is a field assigned a + (or marked otherwise) in the tid file and who is responsible for this?

@felixhayashi I'm not sure what you mean here. The format I've proposed allows both single and multi-line fields. If the user wants a multi-line field then, yes, they need to use the syntax for multi-line fields. I can't see an alternative to that!

The .tid file format is designed to be easy for humans to type. If we lift that constraint then JSON is probably the best choice. I think it's important to support both.

If tje user is responsible for this, what if he/she forgets to mark a field as multiline, does #1955 happen in nodejs?

I think you're asking what happens if the user makes a mistake in the syntax of the file. We'd certainly need to figure out how we'd handle errors.

Also, Where is the sense of marking a field as multiline, shouldn't all fields not ideally simply accept multiline without breaking (just like HTML attributes accept newlines)? So shouldn't we have a robust format that works all the time?

I'm a bit confused here. To recap:

Multi-line fields work fine throughout TiddlyWiki (#1932 and #1955 are both about presentation of multi-line fields, not about making them work). The only problem is that the .tid file format doesn't allow multi-line fields. So we're proposing a new file format that allows for multi-line fields. Which part of that logic are you challenging?

Are you asking for a format which implicitly handles single and multiline fields, without needing different syntax? If so, I think you already know the answer: we would need a format like XML or JSON that doesn't use line breaks to delimit items.

[felixhayashi]

Hi @Jermolene

sorry for the late response, don't know why I missed your message.

Are you asking for a format which implicitly handles single and multiline fields, without needing different syntax? If so, I think you already know the answer: we would need a format like XML or JSON that doesn't use line breaks to delimit items.

You completely summarized my intention here, but please let me answer a bit more thoroughly.

@felixhayashi I'm not sure what you mean here. The format I've proposed allows both single and multi-line fields. If the user wants a multi-line field then, yes, they need to use the syntax for multi-line fields. I can't see an alternative to that!

In my opinion, it is not flexible enough if a user always has to explicitly state whether he/she is using a field for multi-line or not.

An example:

1. Say a user in a browser creates an input field and specifies <$edit-text tiddler="tidA" field="fieldB".
2. Soon he/she realizes that he/she needs to enter more than just a line and changes the widget to textarea, – but of course he sticks with fieldB, as this is his desired field of output.
3. He/She now adds multiline text and unfortunately uses nodejs and not standalone.
4. Too bad. File is broken – just because he/she wanted to scale from single-line to multi-line input.

If the user had used standalone instead, this wouldn't be a problem at all, because xml attribute fields are scalable and can accept linebreaks.

The .tid file format is designed to be easy for humans to type. If we lift that constraint then JSON is probably the best choice. I think it's important to support both.

I like json, though I would prefer xml as it is more flexible.

I think you're asking what happens if the user makes a mistake in the syntax of the file. We'd certainly need to figure out how we'd handle errors.

I think that it should not be blamed on the user or considered a syntax mistake if the user wants to add linebreaks to a field at some point that so far was not multi-line. It should be supported in any case to switch from multiline to singleline input seamlessly.

So we're proposing a new file format that allows for multi-line fields. Which part of that logic are you challenging?

I am challenging the restriction, that a user has to make a choice whether a field is single- and multi-line. Also I am and it is difficult to revert his choice (see my example at the beginning).

---

@Jermolene, I read Eric's comment about export formats in TWC. It sounded like it is actually the same xml snippet that is also used in the store part of the html file. I would not mind using json or any other flexible and easy-to-parse format but it would also be of great advantage, if we simply used the xml (html div) in the html store as external format. This way, both internal and external formats would be completely equal and easy to manage.

[tobibeer]

Hi @felixhayashi, I get the feeling you might be confusing independent things.

In a standalone wiki, a user can enter multiline content so long as the ui caters for it. It is only the persistence layer for node.js that needs a different handling / encoding so as to not break multi-line fields.

However, since "power-"/node-users do edit tiddlers under node directly as text files, it is desirable to have an as simple as possible format that is not only familiar but also flexible enough to cater for multiline content.

The proposed enclosing using certain terminators caters exactly for that ...and is one simple addition compared to the current tid format... to perhaps create an .mtid or .xtid format alongside a .tid format, and at some point possibly use that by default. This would be much the same with any xml or json dialect. We'd need a new file-type.

As for me, being forced to use XML or JSON or any other complex syntax implements an entirely different paradigm, one that I'd rather do without, but would nonetheless surely like to see core support for via corresponding serializers. Other than that, while each of those formats may have its merits, they otherwise seriously deteriorate readability and editability of tiddlers, as far as I am concerned. Clearly, I am talking about looking at a text file here... not about whatever TiddlyWiki does to (de-)serialize that.

So...

In my opinion, it is not flexible enough if a user always has to explicitly state whether he/she is using a field for multi-line or not.

The only time a user would have to be explicit about that, is the time he would have to be explicit about that in whichever format is being used, be that some xtid, some xmltid, some jsontid or whatever format, he'll have to adhere to the basic file syntax to construct properly serialized tiddlers in the target format.

So as for your numbered example, I really don't see how that fits with the problem description because it appears you are talking about a browser context whereas this entire issue is about a backend-textual-single tiddler format rather than that ui on top.

So, even the first line...

1. Say a user creates an input field and specifies tiddler="tidA" field="fieldB".

...does not actually describe anything being used today. So, I'm a little at loss what case you are constructing. Today we write tid files as...

title: foo
field: bar
tags: baz

content content content

...very simply so, very readable, very editable... the one missing link is that in this very format fields other than the text field cannot contain line-breaks since those delimit field definitions already.

Again, yes, we may wish to allow for other serializers / adapters, so that the core can read some xmltid or some jsontid or some mysql adapter... who knows what. Jeremy's first response well summarizes the options we have for all that.

I am thinking that the more we introduce an entirely different format...

• the greater the barrier for adoption
• much deteriorated readability as well as editability
• a whole range of new problems that just come from the quirks of using another format being adopted

...and so I am advocating for a simple, yet enhanced new multiline-tid format that extends the basic tid format by a single rule and that's it.

[felixhayashi]

So, even the first line.....does not actually describe anything being used today

Sorry, I was talking about a user who is working in a browser in his/her wiki. I made it clearer now.

The only time a user would have to be explicit about that, is the time he would have to be explicit about that in whichever format is being used, be that some xtid, some xmltid, some jsontid.

Since you prefer an argumentation from a backend perspective, let me put it this way: If the wiki run in node receives a save signal and has to persist the tiddler content externally, then the format needs to ensure that any field containing multi-line content doesn't cause a crash, right? With xml, you don't have to care about what is multi-line or not, because attributes and text elements support multi-line without escaping out of the box. JSON would need escaping, that is why I wouldn't use it, yet it would work, but then we could also stick to .tid and do multi-line escaping. In all other cases, e.g. using a terminator, you would need to explicitly check if the field has newline characters and if yes, add a terminator, moreover it is not clear if the terminator is already in use in the content itself, which makes it likely to break.

[tobibeer]

@felixhayashi,

Since you prefer an argumentation from a backend perspective, let me put it this way:

It's not that I prefer that argumentation. It is that this issue is about the backend perspective, mostly.

If the wiki run in node receives a save signal and has to persist the tiddler content externally, then the format needs to ensure that any field containing multi-line content doesn't cause a crash, right?

Right.

With xml, you don't have to care about what is multi-line or not, because attributes and text elements support multi-line without escaping out of the box.

That is true. But then again xml is not exactly the most readable or editable text-format. That's why there is a tid format in the first place.

JSON would need escaping, that is why I wouldn't use it, yet it would work,

It's also why I wouldn't use it. There are simply too many rules to both JSON and XML that make it really hard to just write a tiddler from scratch.

but then we could also stick to .tid and do multi-line escaping.

...so, that's why I very much advocate this.

I not only want support for multi-line fields. I want to be able to quickly and easily write such a tiddler... using my keyboard. And I can tell you, I will not do that with XML. Besides, since wikitext may contain XML / HTML ...how would there not be encoding involved in this? Would that not disrupt the simple desire to just create / edit a tiddler comparable to editing in the browser, but then just using a text-editor for all fields at once?

In fact, such a "minimal" editor could even be designed for the browser... and all the perhaps excessive core editing ui be put into a plugin that I may not actually want, i.e. core/edit ...or use an alternative for, that does some auto-complete, doing some regex magic, rather than per-field inputs.

In all other cases, e.g. using a terminator, you would need to explicitly check if the field has newline characters and if yes, add a terminator, moreover it is not clear if the terminator is already in use in the content itself, which makes it likely to break.

There is nothing to break here. The file format will ensure that a given starting and terminating delimiter will demark multiline fields and if you ever need to use that character all by itself, you can... because there would be no terminator.

[tobibeer]

I'm starting to think I'm having this a little backwards. Interoperability IS a big issue.

Therefore, @felixhayashi, that's possibly the one BIG reason to use a generally known format and to more easily handle tiddler data in other systems via simple adapters. XML can be a good candidate for that.

What I don't like about XML is that it's not pretty in terms of human readability... but techy.

Also, while those multi-line field items could literally contain anything, they obviously must not contain the closing tag for that field. This may be the one design problem that begs for encoding :|

@pmario: So, to avoid this problem entirely, I think we can actually use YAML and indentation, so that fieldnames would be top-level identifiers and their contents indented (as needed). After all, the .tid format is an almost yaml-type-construct.

[pmario]

I had a closer look to yaml js parsers. .. since the format is for general purposes, they are all pretty heavy, in terms of size. That's not a problem for the CLI, but I wouldn't want to include it into the browser core :/

If we use a minified version it goes down to about 30k, which would be ok for me.

[felixhayashi]

What I don't like about XML is that it's not pretty in terms of human readability... but techy.

If we simply reuse the TW html store syntax which is a div where all the fields are attributes and the text field is a text node in the body then it is super clear and non-techy and completely analog to what tw uses in the html store.

<tiddler title="XYZ" created="…"  modified="…"  type="text/vnd.tiddlywiki">

your text goes here. Nothing techy about that.

</tiddler>

• All attributes allow multiline input
• No escaping of the text
• @pmario No heavy YAML parser; DOM/XML operations possible out of the box
• May be opened in the browser.
• Absolutely compatible with the html-store code
• JSON doesn't allow multiline

Why not stick with that also as external format?

[webbj74]

If going the YAML route, I hope you will consider "YAML frontmatter" for tiddlers. Jekyll, Grav, and slew of other static site generators use this (usually with Markdown). Markdown files with YAML also get special rendering in Github (see this example - click on Raw to see what the format looks like).

[sukima]

Well here is my two cents. I'm a fan of JSON but It would be awkward in the simple case of the .tid format.

Agreed many systems use YAML front matter. I personally don't like it. And it typically increases the connotative needs of the user. It is, IMHO, a but too techy for most.

My favorite compromise is @felixhayashi suggestion of using HTML syntax. Including all of his bullet points I wanted to chime in and say that the community is moving towards web components. Ember, Angular, and others architect their frameworks to align with the ideals of web components. Using HTML would support this as well.

<tiddler-spec
    title="…"
    created="…"
    creator="…"
    tags="[[foo bar]] baz"
    multiline-field="Multiline
Content">
Tiddler content

Multiline
</tiddler-spec>

I would much prefer this format. That said it still comes with the cost of being techy. Then again if you understand HTML (which is an expectation for those who understand tiddly wiki text) you can grasp the .tid format.

What about two formats. the original .tid which can bee easily wrapped into the new format and the new format another file type .xtid with mime type vnd/tiddlywiki-extended or something.

[Jermolene]

I've had an idea for a much better way to deal with this that will be backwards compatible in practical terms. The trick is to interpret lines within the header that start with a colon to be continuations of the previous field. Lines that begin with a colon in the header of .tid file don't normally occur, and are currently ignored if they are encountered.

For example, here is a tiddler containing a description field containing three line breaks:

title: HelloThere
description: This is a multiline description
:
:* That contains bullet points
:* In a list
modifier: JoeBloggs

This is the text of the tiddler, which can contain

new lines

as usual

The code to interpret .tid files is here:

https://github.com/Jermolene/TiddlyWiki5/blob/master/boot/boot.js#L294-L309

.tid files are generated using this wikitext template:

https://github.com/Jermolene/TiddlyWiki5/blob/master/core/templates/tid-tiddler.tid

The changes we need:

1. Extend $tw.utils.parseFields() to understand the new syntax
2. Extend the <$fields> widget to optionally suffix line breaks in fields with a colon

[pmario]

I like this idea.

But how do we deal with wikitext definitions: http://tiddlywiki.com/#Definitions%20in%20WikiText ?

---

edit: just thought about it. It shouldn't be a real problem. Just me confused :)

[Jermolene]

Hi @pmario - for clarity, the colons would be removed as part of the process. So in the example above, the field description would have the value This is a multiline description\n\n* That contains bullet points\n* In a list.

[tobibeer]

@Jermolene: sounds elegant and very practical, and all the more obvious at second thought ;-)

[tobibeer]

@Jermolene, I get the impression that for implementing this in the respective template, we do need core split and join filters, e.g. try the below at http://tobibeer.github.io/tw5-plugins:

\define field-content-oneline()
gronk
\end

\define field-content-multiline()
mumble
frotz
gronk
\end

\define render-field(name,value)
$name$: <$list filter="[<field-content-$value$>split:keep[
]join[sep:
: ]]"><$text text=<<currentTiddler>>/></$list>
\end

<pre><<render-field foo oneline>>
<<render-field bar multiline>></pre>

[Jermolene]

Hi @tobibeer that's neat. The alternative would be to add a custom JS macro to handle the format, as we do for JSON output:

https://github.com/Jermolene/TiddlyWiki5/blob/master/core/modules/macros/jsontiddlers.js

[tobibeer]

@Jermolene: yes, please. Clean rendering, no wikitext fiddling when it overly complicates things unnecessarily and would probably be awful in terms of performance.

[diego898]

just want to gently bump this issue!

[diego898]

Another even gentler bump!

[Jermolene]

Referring back to my original response to @tobibeer, I recently implemented the following proposal:

Automatically detect attempts to save a tiddler with fields containing line breaks, and switch to saving in JSON format instead

The implementation is here: 7fcd2f132e91aa375a1fece501b14e991ba1bd4c

[rimi]

Hi,

just to understand that right: when i create a tiddler with a text-content <$edit-text field="my-multiline-field" tag="textarea"/> and add several new-lines into that area, node.js-TW5 should create a JSON-formatted Tiddler instead of a standard .tid-File? I'm using v. 5.1.19 and what i get in that case is a broken .tid-File that cannot be loaded after next node.js-Restart. Am i missing something?

Regards, Mirko

[Jermolene]

Hi @rimi the fix in 7fcd2f1 is merged into master but won't be released until v5.1.20 -- hopefully in a few days. You can try using the prerelease by downloading/cloning the repo instead of using npm -- see the instructions here.

[rimi]

Hi @Jermolene, thank you for your quick reply!

[pmario]

@Jermolene ... IMO this issue can be closed?

[pmario]

@Jermolene -- Can be closed. We do have multiline field support now.

[Jermolene]

Thank you @pmario