I know there are many ways to edit and save content without clicking a button. For short ideas, I also use edit-text to quickly edit and then click a button to automatically save it as a tiddler.
But that’s not what I want to discuss. I want TiddlyWiki to be like other note-taking apps where you can open a tiddler and start editing immediately, with changes being saved by default. This would eliminate the extra steps of clicking an “edit” button and then a “save” button.
I also use TiddlyWiki for more than just note-taking, like for a blog, task management, or as a reader. However, I don’t think this is a reason for TiddlyWiki to not make a change. Obsidian and SiYuan Note, for example, both offer a reading view that can be set up as a website for others to visit.
No, I didn’t think you were suggesting that. Since you offered it/Obsidian as an example, I wanted to establish
How it is rendered in Obsidian — not the technical, behind the scenes details, but what the user experience feels like, and
What aspects of this user experience do you think TiddlyWiki is missing?
As I said, I’ve never used Obsidian, and in my admittedly brief investigation, what I saw of how it handles editing of complex, widget-like features (like Dataview) looked a lot like TiddlyWiki. But you’re certainly more familiar than I am, and I’d gotten the impression that you thought Obsidian offered a better editing experience, so I’d hoped you could expand on the ways in which you think that’s true.
Wouldn’t we then lose the draft system — the ability to work on a tiddler (or multiple tiddlers simultaneously), even across multiple sessions of TW use, without immediately overwriting existing content? I think the ability to test changes (e.g. with the preview window) before committing to them is actually a major strength of TW — especially since a malformed filter can have major consequences for rendering, and may even freeze/break the wiki. I’d hate to think that there was no easy way to roll back a bit of code that had caused a RSoE error.
I believe the existing edit-and-save process for tiddlers in TiddlyWiki is a significant area for improvement. The repeated cycle of editing and saving wastes a considerable amount of the user’s time and attention over thousands of edits. In my opinion, this workflow discourages users who want to quickly capture and input ideas. While long-time TiddlyWiki users may have grown accustomed to it, I think it’s a critical flaw that hinders wider adoption.
To change this, the draft mechanism would likely need to be re-evaluated. An early advantage of TiddlyWiki was the ability to edit multiple tiddlers in the story river at once. I’ve always had a different view on this, as modern word processors and note-taking apps also allow you to edit multiple documents simultaneously, often with easy-to-switch tabs or side-by-side views. The difference in TiddlyWiki is that you have to scroll to a specific location to find and edit a tiddler, which I find to be a time-consuming process, especially when I have many tiddlers open.
I see the draft mechanism as a double-edged sword. While it provides a way to preview changes before saving—acting as a safeguard against errors—many modern note-taking apps also offer a preview function without requiring you to click “edit” and “save” buttons. Furthermore, drafts don’t completely prevent issues. Users will inevitably write incorrect wikitext, and relying solely on a draft mechanism isn’t a sufficient protection. Everyone needs to back up their TiddlyWiki files, and the ability to roll back changes is essential to avoid data loss.
I think we’re broadly in agreement. I’m not very fond of the default tiddler edit mode myself; I use a lot of custom view templates that let me make real-time “inline” edits when I’m adding wikitext content, and in these instances I do bypass the draft-editor completely. But even these custom templates have inline edit/save buttons to toggle between viewing and editing, and I still can’t conceptualize any workable alternative.
In a WYSIWYG envionrment (most word processors, for instance), you’re effectively always in “edit mode”, and this is possible because you’re never writing any complex script: instead, changes are handled by buttons/keybindings. But while we have some examples of WYSIWYG wikitext editors, like Saq’s Typewriter, I’m not sure how they could handle more complex constructions like widgets or procedures. For that, I think you really need an editing mode to work with the unrendered code, and a viewing mode to render it. This is why I asked how programs like Obsidian handle it: I wondered whether they had found some hybrid solution that hadn’t occurred to me. From what you shared (and my brief Googling), it doesn’t look like they have — but I’m very open to correction.
I think the fundamental issue here is that, in TiddlyWiki, everything is a tiddler, and in vanilla TW, all tiddlers can be edited using the same mechanism. This creates a fundamental tension between what’s optimal for editing simple wikitext notes (in which case a WYSIWYG environment would be ideal) and what’s optimal for editing template tiddlers (likely to contain far more wiki “script” than wikitext) or the functions/procedures/widgets which are themselves used as building blocks elsewhere in the wiki — for which it’s helpful to have an “editing” step in which changes are not applied in real-time.
Vanilla edit mode does offer some alternative UIs depending on the type of tiddler; an image tiddler or a data dictionary has different editing options than a standard tiddler. However, these alternate edit modes are applied on a per-tiddler basis; they don’t handle “mixed” cases, which may use wikitext and wikiscript in the same tiddler or even in the same paragraph. I think a system that prioritized WYSIWYG text editing would be less flexible in where and how you can use (and edit) wikiscript.
Addendum:
I agree! But they do reduce issues. I do backup my wiki regularly — every time it saves. But it would still be inconvenient to have to go back to a previous save just to revert a change to a work-in-progress tiddler. I appreciate that the draft system doesn’t overwrite a previous version before I’ve had time to do at least some first-pass scanning for potential problems in my code.
The clever thing about Obsidian is that you edit the current line in plain text, while the rest of the text is rendered. They used this in Dynalist as well. So you get the best of two worlds.
I suspected that might be the case. Thank you for confirming.
I can certainly see the appeal of this approach. (IIRC, @TW_Tones was requesting a line editor not too long ago… yup, found it.) I’m just wondering how it would handle instances in which a construction spans multiple lines or even multiple “paragraphs” — say, a procedure which has its parameters defined on one line, and its contents beneath that, or a $list template that encompasses multiple lines. And for that matter, what do I click on in the rendered view if I want to edit a filter or a widget parameter?
Mohammand’s Section plugin neatly avoids these problems by breaking up “sections” only at the headers, but I’m struggling to see how you could get more granuar without running into the above issues. How do you distinguish between tiddler content that can/should be editable inline in view mode and content that can’t?
Since a tiddler may have not just formatting markup but also list widgets, transclusions (with or without templates), etc., clicking on some part of it (that is not a link, presumably!) would show a cursor so that I can edit… what exactly (if there’s any kind of widget or transclusion going on)?
I could imagine having the story river check for whether a tiddler is … “primitive” (I think we’ve been around the block before with terminology for this — a tiddler that seems to be just “flat” — without further refractive/transcluding layers), and displaying just those tiddlers as inline-editable.
I also recall trying out some modification intended to give a translucent-reddish-background visual cue for transcluded content. Maybe such an interface could help visually orient us to the “tiddler-level” editing “canvas” of a tiddler, as distinct from windows into content stored and/or templated elsewhere… Something like that might help make a live-edit solution workable. (Presumably there’d still be a need for toggling into edit-mode for tiddlers whose view-mode needs to display dynamic dimensional content.)
Couldn’t you use the type field to distinguish “WikiText” that shouldn’t be rendered when editing from “normal text” that can be edited inline? In almost all cases content can be categorized as one or the other.
If you want to focus on taking notes, you won’t need WikiText anyway, so use the inline edit mode. To create templates and other functionality, use WikiText mode by setting the field accordingly.
Those of us who use the Markdown plugin already sort of have this dichotomy, as Markdown tiddlers cannot contain advanced WikiText. Those kind of tiddlers could in principle be edited inline already. Now, if we could also change to Markdown as the default markup language…
I’d like to push back on this claim a bit. While all my complicated code lives in view templates, I have a lot of otherwise “normal text” tiddlers that contain a widget or two — often $list — and this feels like a relatively natural way to use TiddlyWiki. IIRC, many of the documentation tiddlers do it!
I think making the “default” tiddler type one that doesn’t support most TW-specific features would be hiding away what makes TW unique — i.e., the reason you (generalized “you”) probably chose it over Obsidian in the first place.
On the other hand, I can imagine considerable overlap between people who prefer Markdown to wikitext for “normal tiddler” notes and people who’d like in-place editing. Perhaps it would be reasonable to prioritize including an in-place editor in the Markdown plugin, and make markdown-type tiddlers the ones that default to inline editing?
Most of mine are – at least, “content” tiddlers are, though not “code” tiddlers, for obvious reasons.
@dongrentianyu Any tiddler placed in $edit or $edit-text widgets is editable. No click to edit, no click to save ← no draft mode, either. It’s not WYSIWYG, of course, but that’s not so much of a problem if you provide a preview (or two).
I appreciate you’re talking about an off the shelf TW, but it’s not so hard to step out of the workflow you dislike and build something nearer to your liking. First step would be to free yourself from the story river, stop “seeing” tiddlers as “rendered blocks” in the river (open for editing or not) and build an editing interface that isn’t the regular TW draft-mode editor.
To build on @CodaCoder’s customization suggestions:
I agree, this is tedious — but I think, at its heart, it’s an issue with the story river, not the editing mechanism. The first thing I do with any new wiki is always switching it to Zoomin storyview; I’d recommend the same (or other single-view alternatives — plus navigation tabs, if you want them) to all my fellow story river haters.
I recognize that you weren’t asking for recommendations and may not need them, but I’ll leave a few here anyway in case anyone with similar desires would like some currently-available options:
Not-quite-off-the-shelf enhancements for your editing experience
Navigation tabs solutions (generally work best with Zoomin):
Unfortunately, I find it rather difficult to find demos for specific plugins in the CPL, but I know I’ve seen more modern tabs-based layouts there, too.
“Live-edit” alternatives (other than WYSIWYG options, several of which have already been shared in this thread)
@twMat’s SideEditor (which can be popped out into an external window)
“Quick edit” tab in the sidebar: shared here by @diligent_path; @Mohammad’s Narenj; possibly others I don’t have to hand at the moment
IIRC @TW_Tones had a variation on the open-in-external-window button that opened an edit-mode window instead. I think he originally shared it in the Google Group, but perhaps he still has a version he could link.
Yes, it works. It includes a few tiddlers written in WikiText and styled with CSS. Adding a sidebar tab to display the rendered tiddlers could be a good idea.
Your TiddlyWiki can be like this, I dont want our tiddlywikis to be like this.
Sure we can find a way to implement WYSIWYG and much more but we can do this in tiddlywiki on a needs basis. I dont think changing the tiddlywiki core is necessary. At the beginning of Tw 5.x I sought this but quicky abandoned it in favor of wiki text entry. A couple of things that helped are as follows and I suggest you try them before going too far as they are very close to what you are asking;
When editing a tiddler you can use the Editor Preview and select output. You can see a live WYSYWIG in the preview (Although I suggest you turn this off if you are writting TiddlyWiki Script to avoid partial code throwing errors or infinite loops) I mention this although I expect you know this @dongrentianyu but your words do not acknowledge this.
If you install $:/plugins/telmiger/EditButtons you can save the tiddler periodicaly without closing the tiddler “Save and keep open”
With local storage plugin installed the last changes are immediatly saved such that if your device restarted you can return to see the last character you typed. When editing the draft tiddler every character is committed to that draft tiddler, however you retain the ability cancel applying your changes, but also any standard undo and redo.
It is trivial to leave tiddlers in edit mode and even make a button to bulk switch tiddlers into edit mode, with or without the preview window open.
I can see value in WYSIWIG but to me it is only of value for naive users, visiting a tiddlywiki for the first time and giving them the opportunity to compose content with a rich text format style.
Personaly I like the power the Wikitext engin gives me over WYSIWIG especialy in the case of taking notes live in a training session. An example is using ctrl-L to insert tiddler and html links, custom editor toolbar buttons, hidden comment blocks (by definition not WYSIWYG)
To do this on a per paragraph basis consider the streams plugin and if desired include the fusion tool to convert a steam to wikitext.
I returned to TW (after enjoying TWC, then being put off by TW5 when it was first seen), via a swing through using (largely simultaneously) the note taking apps of MacOS Stickies, Linux StickyNotes, and mostly, tomboy notes (I mostly used the gnote implementation, but the file format is still tomboy).
The gnote interface is still basically my ideal for the editing UI of simple notes. It’s WYSIWYG with nothing really more complex than what wikitext or markdown provides (headings, lists, bold, italic, etc). It also auto-detected links to other notes and linked them (baking it into the saved code). Otoh, the saved code is XML and in parsing them (to auto-convert them to .tid) I had to handle empty and repeating formatting blocks for no ongoing reason (imagine: <bold></bold> or <bold>hello</bold><bold> world</bold>).
For those reasons, I see this suggestion and it appeals:
otoh, adding a little bit of wikiscript to an existing block of content is not something I think should require a refactor from markdown to wikitext - in fact, being able to trivially add a bit of wikiscript without changing editing type, is a benefit here. It reduces the distance from note making to code writing, and encourages the possibility of a note maker becoming a code writer. ie, the path from beginner user to power user is obvious (though that’s different to easy).
A WYSIWYG editor for simple content formatting, and a different editor for the code that generates content? That might encourage more beginner users, but starts discouraging the path to power user, and makes it less obvious. It’s a tough tradeoff
I think it’s worth remembering here that almost by definition of being active in this forum and reading these threads, we’re likely not representative of all users. Maybe a clean WYSIWYG edit-always mode by default would attract enough new users to be worth the offset of less obvious level-up path?
I also got thinking about having wikiscript within markdown formatting - it would have benefits for beginner users not having to learn a new markup, whilst keeping the user level-up path a little more open. But I suspect implementing that idea would have it’s own mighty headaches (based on my usage of Homebrewery and the amazing formatting it wrangles into markdown, I’d bet it’s possible, but potentially messy.
tl;dr: Sometimes (usually?) I really just want to write notes, and a WYSIWYG that saves sane markup but doesn’t show it, REALLY appeals. OTOH, it adds friction to switch to code writing mode, and I’m hesitant about changes that may discourage code writing.
If you mean wikitext, then you can include it, as long as it is on one single line. That single line might have the complete <$list>....</$list> syntax in it.
I was making the distinction between the wikitext that handles formatting, vs the wikitext that handles code. Calling both “wikitext” is a hinderance in this situation and others above referred to it as wikiscript, so I was just following that usage.
I had forgotten it could be embedded though - thank you for the reminder of options! However forcing everything into a single line means it’s not a viable regular usage