I believe the TiddlyWiki editing experience is its most significant area for improvement

#16

Well, if you don’t mind modifying core tiddlers, a small change to eventcatcher.js would make this work.
First we need a new parameter to activate this behavior, since it might not be wanted for all double clicks:

stopPropagation = self.getAttribute("stopPropagation","onaction"),
cancelOnSelection = self.getAttribute("cancelOnSelection","no"),
selectedNode = event.target,

Insert the middle line between the other two. This gives a new parameter cancelOnSelection which you set to yes if actions should not execute when text was actually selected by the double click.
Then,

if(event.type.toString() !== "dblclick" || cancelOnSelection === "no" || window.getSelection().toString().trim().length === 0) {
	self.invokeActionString(actions,self,event,variables);
}

Wrap the already existing middle line into the conditional statement.
Now, if the event was a double click, the actions are only invoked if the parameter cancelOnSelection is either not set or there is no selection.

<$eventcatcher $dblclick=<<actions>> cancelOnSelection="yes" >

Your actions would be to send the tm-edit-tiddler message. The eventcatcher itself would have to be added to the ViewTemplate.

1 Like
#17

A couple of questions for anyone with more experience with modern note-taking apps, especially of the WYSIWYG variety:

  1. How do they handle drafts? (Or do they?) I don’t use the standard TW edit mode very much myself, but I do think one of its major strengths is that you don’t have to commit to any changes before you’re ready — and you can even save a wiki, including all your current drafts, without ever leaving edit mode.

    I think this can be especially helpful when editing multiple tiddlers at once: if I’m cutting content out of one tiddler and pasting it into another, I don’t necessarily want those changes to affect the “live” tiddlers until both are in a finished state. And I wouldn’t want all my changes to be permanently committed the moment I click into another tiddler.

  2. How do they handle more complex code like widgets? I can see the utility of WYSIWYG if you’re not doing anything beyond basic text formatting… but I’m struggling to see how it would work with a $list widget, for instance, or even a transclusion. Surely you’d want to preserve a visual distinction between transcluded content and content actually present in the tiddler you’re editing. How does this work if you’re always seeing rendered results — especially if there’s no distinction between edit and view mode?

1 Like
#18

I know there are some keyboard shortcuts that can help, but I generally don’t use them because remembering all of them can be a hassle. Another key issue is that they often conflict with other software on my computer. Furthermore, shortcuts don’t change the fundamental “edit and save” process; they just remove the need to use the mouse to click the buttons.

#19

That’s a good question, but it’s primarily a rendering issue. Imagine you have some Mermaid code. If you change the code, the rendered diagram has to change too. Similarly, when we want to edit a widget like a list, we’re editing the underlying <$list> code, not the rendered output directly.

Of course, the code can be short while the rendered content is long, so keeping the two in sync needs more research. Maybe we could add a delay or a special button for a manual refresh.

In Obsidian, there’s a popular plugin called Dataview, which offers functionality similar to <$list>, and even has a more complex UI. Yet, the rendering issue hasn’t been a problem for users. From what I understand, many people love Obsidian precisely because this plugin allows them to organize their notes more extensively.

#20

I’m not familiar with Obsidian or Dataview, so I looked around and found some screenshots that seem to demonstrate the way it works, courtesy of this blog:

What you’d type:
icefishing1

This is apparently the Dataview syntax for “all files that link to the current file but do not already have a link in the file”. It seems equivalent to {{{ [<currentTiddler>backlinks[]] -[<currentTiddler>links[]] }}} (or perhaps a $list widget version thereof — I’m unclear on whether Dataview allows you to assign display templates to your results.)

What that would give you:
icefishing5

So… this looks more like edit mode than WYSIWYG to me — perhaps with double-click-to-edit? It’s not clear in the screenshots I found, but perhaps Obsidian also supports editing a single section at a time1, rather than editing the entire note (or “file”) at once?

If so, it looks like you’re still clicking to enter/exit editing mode. And you alluded to the division between code and rendered output, too:

I guess my question is, how do you see an improved system differing from the editing methods we already have? Is the “section editing” the most important aspect?

1 For anyone looking for section editing in TW, @Mohammad’s Section plugin is a good starting place. In theory, it might be possible to modify his plugin so that it splits editing “sections” at the paragraph level rather than at headers… but linebreaks can convey parsing information in TW, so I’m not sure whether this would really be a good idea.

1 Like
#21

Keep in mind if you include items in the view template that appear on selected tiddlers, you can introduce code to edit the current tiddler. Typicaly we would not edit only parts of a tiddler with tiddlywiki script in the text field but edit specific fields on the tiddler. These fields value may then be referenced via the template or in the body such that a change to a field is reflected the output.

There remains three ways (at least) to edit a field, in edit mode, in a temp field/tiddler then one done update the field, or edit the field directly (which may cause issues if only partially edited.

I am working on [Proposal] Updating field handling functionality in TiddlyWiki with a view to providing better ways to edit fields, but ultimately this can be used in view mode via the view template.

#22

While I’m not a fan of WYSIWYG, I created a liveNotes using just a few lines of wikitext, and it works simply and quickly. The real tiddler are stored under $:/livenotes/data namespace. It can be extended for simple note-taking. On the other hand, the typewriter by @saqimtiaz offers a complete solution with a minimal UI.

image

3 Likes
#23

I think you’ve misunderstood. I’m not suggesting we port the Dataview plugin from Obsidian to TiddlyWiki. I was simply using it as an example to explain that even with TiddlyWiki’s extensive use of wikitext code, the rendering issue can still be solved. It would just require rethinking how rendering and styling are handled. Of course, this would involve changes to the core design, so I’m just raising it as a potential feature.

#24

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.

#25

No, I didn’t think you were suggesting that. Since you offered it/Obsidian as an example, I wanted to establish

  1. How it is rendered in Obsidian — not the technical, behind the scenes details, but what the user experience feels like, and
  2. 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.

#26

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.

#27

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.

#28

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.

#29

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?

#30

I forgot about that. It’s really beautiful.

Does it work with 5.3.6 ? The problem with Saq’s typewriter is that it crashes modern TiddlyWiki.

Your screenshot shows a different font than the demo. How do I change that?

Thanks!

#31

I’m perplexed about how this would work.

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.)

#32

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…

#33

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?

#34

Perhaps ProseMirror.

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.

#35

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):
    • BuggyJ’s StoryTopTabs
    • Ton Gerner’s Tiddlersbar
    • @Brian_Radspinner’s Be Rad edition (uses a non-standard layout)
    • 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.
    • Somewhat related: @Christian_Byron’s separate-window preview, and other expansions in the same thread
  • Tutorial: A basic alternative layout - also courtesy of @Brian_Radspinner; a good starting place for anyone who does want to build their own ideal layout, as @CodaCoder suggests.