Well, for the time being I guess it’s good it’s mentioned here along with the modification I attached so others trying it know what to expect.
I’m not sure I see much difficulty with JSON formats though, I have next to no experience with JSON or javascript but it seems fairly straight forward in the way it’s saved when opened with notepad or VSCode.
Does it appear differently in node.js?
not that it’s related, but what is the history behind the .tid format?
.tid does exist since the very beginning. It’s a simpel plain text format, that can easily be edited with a simple text editor by humans. eg:
title: my tiddler
tags: test [[tag with spaces]]
test-field: test
text line 1
text line 3
That’s basically it.
Multi-line fields and unrestricted field names have been introduced with v5.2.0. It gave users more freedom inside TW. But it has a consequence for the .tid file format.
The same tiddler as JSON looks like as follows. It’s still editable, but as you can see the text field which has several lines use \n to represent line-breaks. This makes editing for humans much more challenging.
Fields with multi-line content will also use “\n” for line-breaks.
[
{
"created": "20230710194940971",
"text": "\ntags: test [[tag with spaces]]\ntest-field: test\n\ntext line 1\n\ntext line 3\n",
"tags": "test [[tag with spaces]]",
"title": "my tiddler",
"modified": "20230710195327262",
"test-field": "test"
}
]
hope that makes sense
-m
Hm, that’s pretty neat to learn honestly.
Very beginning as in before TiddlyWiki, and beginning of wiki software, or TiddlyWiki’s beginning?
I imagine changing the format would make them no longer backwards compatible, which would be a bit of a problem.
I was going to recommend having .tid files wrapping their fields in quotes like JSON does, or using wikitext within them for multi-line, like
title: my tiddler
tags: test [[tag with spaces]]
test-field:
"""
test
text line 1
text line 3
"""
text: Hello there, `here is some code`
I think that would be kind of neat since you could then use wikitext in any plaintext document and change the suffix to .tid to import into a tiddlywiki
---------- We are going way OT now … But it’s your thread 
-------
IMO the main problem is that nobody else can read that syntax. So it will be one more island-solution only valid for TW.
The following syntax is a standard named front matter, which can be used within markdown files.
---
title: my tiddler
tags: test [[tag with spaces]]
test-field: |
test
text line 1
text line 3
an-other-field: short text
---
Hello there, `here is some code`
The disadvantage here is that it needs indentation. The advantage would be, that it could do a lot more than just multi-line fields.
-m
Yea… I tend to do that a lot if I’m being honest, my curiousity gets the better of me. My solution is making a new thread for this then!
Hm, well, Markdown wasn’t always around either, it had to start somewhere I imagine, so tiddlywiki having it’s own file formatting isn’t too outlandish. Plus, I would argue wikitext (I usually call it TiddlerText or TiddlyText) is more readable than markdown, but that is just my own opinion.
Seeing how markdown handles multi-line text looks even less appealing as what I proposed, if I’m being honest. What are the advantages it brings, that you mentioned?
The indentation would only be needed for multi line fields. The text area is the same as TW wikitext.
The advantage would be that it’s a standard, that most markdown tools can understand out of the box.
Ah ok, yea that makes sense
Still can’t say I’m a fan of markdown though, but why was talk of multi-line fields never concluded?
Were there other issues that appeared other than the ones I ran into?
If you needed multiline fields you would use a tiddler and its text field is possibly why there has not being much presure for it. Now multiline fields are feasible I expect to see more uses.
Why would you want to have tiddlers in human readable format that you can edit add seperate files? When tiddlers are inside a wiki you can do more, a lot more!
As I said using a custom exporter you can export in whatever format you want and even build your own importers.
I must of missed that, because that sounds like a future project to me haha