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!
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.)
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?
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.
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.
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.
Ah. Just needed to install “Handlee”.
I have the similar editing experience in TiddlyWiki and would like to have some better editor.
I take an alternative method using VS Code as the editor of TiddlyWiki configured in node.js and am developing a vs code extension to directly edit tiddler (GitHub - byzheng/vscode-tiddlyedit: Seamlessly edit and manage TiddlyWiki tiddlers within VS Code using a REST API connection.).
With this method, I
- open, edit and save a tiddler from vs code editor and take all features in vs code.
- preview a tiddler in TiddlyWiki after saving in vs code.
It is a very smooth process especially I have dual monitor setup.
1 Like
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.
1 Like
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
https://unieditor.tiddlyhost.com/ is a code/hightlighter editor for tiddlywiiki (and wikitext), it has improved undo/redo and limited ‘wysiwyg’.
4 Likes
I agree that the editing experience is the biggest point of friction in TW. I would like to see 5.4.0 adopt a more modern editing system.
My ideal editing experience would match Obsidian or other common tools. It’s “plain text” (just like the current Edit mode!) but renders itself when the insertion point is not inside the element. This would let you write a list widget the same way you do today, and would be much faster for capturing ideas.
I don’t want a rich text editor. I think the editor toolbar mechanism is sufficient for folks who want a GUI for formatting and inserting lists, links, etc. (and it is fully compatible with the plain text experience).
1 Like
Presumably, this would rely on an $eventcatcher widget to process focusin and focusout events. But how would this deal with widgets that can have the input focus when shown in “view mode” tiddler content, such as $edit-text, $select, $checkbox, $radio, and $button (which also includes “tabs”)?
-e
to me a version of preview is enough of wysiwyg and an option to display above or below the text editing may help.
That single line can be a transclusion. Or a macro that transcludes and provides a link, so you can quickly navigate to where the other text is.
Which brings up the other problem with the editing experience. The preview doesn’t synch with the text that you’re typing. By contrast, the editor here in Discourse does sync.
Even a simple fix, like a preview that always scrolls to the bottom (or top) would be better than the current situation.
