Project 2036: the future of TiddlyWiki

100% agreed to this.

My first TW usage was 2009 with TW Classic, and the doubleclick-to-edit made for a very low barrier (at the time) to move between reading/editing.

In the last few years, my note taking has mainly been in tomboy/gnote, which does as you describe - provide a richly formatted visual output in the window which is editable at any time. There is no distinction between a reading and editing mode.

Returning to TW in the last year and picking up TW5, the loss of doubleclick-to-edit I was originally disappointed with, though there is a plugin which implements it and I’ve only set it on one of the several TW I have. The problem being that sometimes I want to doubleclick-to-select, so adds frustration in another direction. (“doubleclick = edit only if no text is selected” is an idea I’ve thought of, but I need to learn JS coding before seeing if I can tweak the existing for that)

Anyway, for my taste, tomboy/gnote style “the viewer IS the editor at all times” distinction would be wonderful - and keep a dedicated “edit the markup directly” mode for the power user gurus who want to get their hands that little bit dirtier!

(I do think an always-an-editor mode needs a more powerful undo/view-old-revisions history though, since the chance of accidentally “I typed in the wrong window and didn’t realise it till later” is much higher. I use TW via node so I get tiddlers as individual files, and shovel the whole thing into local git, but a more integrated solution would be great (and indeed, some of David Bovill’s demonstration (on the "Hitchhikers TiddlyWiki All-Nighter) of running local shell code via TW feels like a potential great step in that direction)

1 Like

That’s how my TWs work, for the most part.

Edit your tiddlers through another tiddler[1] – call it your “master editor”. Let it navigate through your tiddlers, selecting them for editing. Viewing them in the story, they update “live” as you type in your editor.

Whoever it was that said, “the only limit is your imagination,” was dead right. Stop looking at the way TW is presented on tiddlywiki .com as “the only way”. TW is not hardware – it was built to be modified. TiddlyWiki puts the soft back in software.

[1] Take great care modifying macros and css live. And by "great care" I mean don't do it.
1 Like

Correct me if I’m wrong, but what you describe sounds like the editor is still separate to the display though, but instead of needing a preview pane to the editor, the edits are reflected live instantly? It definitely sounds neat and I’m interested to know how you did that, but it’s not what I imagine as the ideal.

Many of the comments here make good points. Things I’d like to see TiddlyWiki improve on going forward:

  • Live WYSIWIG editing like @linonetwo’s slate-write. This is “table stakes” for apps in this category today.
  • A more official shared / community plugin repository system. The TiddlyWiki plugin repository could point to CPL, Relink, Kookma, Fibbles, EvidentlyCube, etc. - the plugin repositories that contain so many handy utilities. Maybe some of these could become “Recommended” by the core (Relink or TW-Commander, for instance).
  • Document and extend the tiddlywiki command line interface. Give examples, and simplify common operations (for example, rendering a tiddler or filter for a single-line wiki should be as simple as tiddlywiki my_wiki.html --render "Index" and write to stdout).
    • Blur the line between single file and NodeJS wikis. It’d be great if I could trivially “explode” a single file wiki, edit the files, and then “implode” it back.

I’d also like many of the features that have open PRs - dark mode customization, AI integration, AST node serialization - to land, but I know that this takes time.

To import a single file wiki into a NodeJS one, you can do

$ tiddlywiki newwiki --load path/to/file.html

It works even if the single file wiki is password protected:

$ tiddlywiki newwiki --password 123 --load path/to/file.html

I have created an older thread regarding this months ago, expressing my concern that this leaves the plain text password in the shell history file though.

To export it back, after editing the files, you can do

$ tiddlywiki newwiki --build index

Am I misunderstanding this part and you mean something else?