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.
Thatâs great! Itâs similar to how editors like Joplin work, where they semi-render the text in the editor mode.
It might be a little fragile â this is what I get if I try to type in a transclusion. I can fix it by opening/closing the tiddler, but it happened with the very first thing I tried:
That just looks like changing which extra hoops are being jumped through, so there remains a friction to using wikicode with markdown.
This is pretty great! Iâve not used Joplin that @Mark_S mentioned, but discordâs text entry has similar inline interpretation of the markup.
If it can be gotten rock solid, Iâd vote for this (or this type of thing at least) to be part of TWâs future at a low level (core, or standard plugin?).
A note for anyone testing this, I just found via trial and error that the Highlight plugin needs to be disabled before unieditor works.
That is not really an error with the editor. To avoid that happening the auto closing of brackets can be turned off in the options:
Actually unieditor works with the Highlighter plugin: https://unieditor-hljs.tiddlyhost.com/
What is happening is uneditor needs a syntax highlighter to work, but the Highlighter plugin doe not support wikitext, however the tiddlyprism plugin does support wikitext.
I guess if Highlight and tiddlyprism are both installed Highlighter takes precedence.
Good question. I wonder if Obsidian has a reference for how this works. At the very least, you could imagine that if input focus is not editing the tiddler, you could render these controls normally. Maybe theyâre disabled? Or running in some different state?
TiddlyWiki for power users: Instructions:
alt-N to create new tiddler
tab twice to bypass the tags and go to the text field
tab to the type field; use up and down arrow to choose
tab to field names and then field values
field value could be anything EXCEPT the title. Eg. tags: irrelevant-tiddlers delete-later , caption: this and that , created: 202508171128 , text: The text of the tiddler is here.
Made a mistake? type the field name and value again and they will be overwritten.
CTRL-Enter saves the tiddler.
CTRL-S saves the TiddlyWiki.
If your mouse is not working: press F7 and youâll be able to move about the page for other buttons. âPressâ the buttons using the SPACE key.
There is a need for some Keyboard Shotcuts. For Importing, navigating the story river, etc.
Was this helpful?
Thank you for your response. I was already aware of all the points except for the last one.
Iâve reconsidered, and I think this change would involve a lot. TiddlyWikiâs core is incredibly complex, allowing advanced users to build very sophisticated interfaces with all sorts of functions beyond simple buttons, lists, and tables.
It seems like this would require a fundamental restructuring of the system, essentially placing the rendering logic below the editing logic. The priority would shift to handling edits first, and then executing the rendering process. This means a significant portion of the core would need to be rewritten. It does seem like a very difficult and ambitious goal.
I donât comprehend the difficulty itâd take to make this happen, but I wholeheartedly believe that a way to edit tiddlers without going into edit mode would be a major improvement.
I prefer using the keyboard but when Iâm navigating around in TiddlyWiki and see something i want to add or remove or change in simple text tiddlers, having to select the tiddler (which is something that I have to do even when using shortcuts unless itâs the last opened tiddler) and then having to go into edit mode is a pain because once Iâm in edit mode I have to find the place within the tiddler again (for a second time because I saw what I wanted to edit a few seconds ago but now itâs in a completely different place), and then after changing, having to save changes to the tiddler adds more friction as well. (But saving is less bothersome than having to find where i wanted the change to be)
The Typewriter plugin would be pretty much perfect if it was faster and the links would work. If tiddlers would by default be âtypewriter enabledâ and then with a button/field/tag that would change to âtypewriter disabledâ (and this default could be changed in settings so the button/tag/field would have to be added for the opposite effect) that, i think would be the best of both worlds.
Some advanced editors even allow for a completely keyboard-driven workflow, eliminating the need for a mouse.
I donât know how thatâd work but that would be awesome!!
I think an advanced version of bullets plug in Bullets â Enhanced list editing by @stobot combined with a version of contextmenu plug in Implementing a contextmenu with wikitext - #35 by Yaisog by @Yaisog that works in edit template can solve this problem with wikitext alone.
I assume it was originally meant for other syntaxes. Could it be triggered to do markdown ?