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 ?
One thing that makes it harder to use TW for actual note-taking is the fact that you can’t pop-up a single note for editing. You can pop-out a single note for viewing, so why not have that for editing as well?
It should support most languages.
for markdown create or modify a tiddler called $:/config/EditorTypeMappings/text/markdown and put uni as it content
markdown tiddlers of type text/markdown should now have a highlighted editor
Hmm – Probably because no one requested it yet at GitHub. I did a hacky proof of concept and it seems to work. Not sure if there are more nasty side effects, other than listed below. It seems to be possible with enough time.
test-edit tiddlerSo there is definitely quite some time needed to iron out the hickups. But it is still interesting.
Long ago I made additional open in new window buttons, to also view and edit in new window, but the same could be done with modals, The point being, it is alredy possible to do these things and people have. Its nothing new, but perhaps people need to know what as already being done by individuals.
I find I have wanted such features but in practice dont use them when they add a need for more work to use and keep track of them.
Tiddlywiki is not an editing software like VSCode, but rather a publishing platform like WordPress. In other words, TiddlyWiki is an interface for submitting data and displaying content based on a database.
Real-time saving in edit mode is a feature that TiddlyWiki does not currently support.
The interface in TW for taking notes is too big and too cluttered.
When you’re actually taking notes you want to just type in the notes you need, not haul along a whole system of things you don’t need. In particular having to drag around the url bar, the bookmark bar, the extensions, etc. associated being in a browser window is problematic.
Currently when I’m actually taking notes, I’m using notepad or something because TW is just too cumbersome.
I would like to float just a note next to a YT video or in one corner and be able to jot notes without clutter. To put two notes side-by-side to transfer text between them. To arrange a series of notes on the screen to compare and contrast. Position notes about backups next to the terminal where it’s happening. To quickly jot down a new password but keep it upfront where I won’t forget to file it later.
To my mind the question is the other way around – why have it in view mode and not have it in edit mode, where it is much more useful? If you try it in view mode, you are almost immediately struck by how useful it would be to edit the note floating on your page.
I have done something like this, but (1) it made only one instance (not multiple notes) and (2) a lot of screen space was taken up and (3) it didn’t remember the pop-out status between closings.
I can see how these alternate ways of interacting with tiddlywiki may suit you, and others. Whilst I am quite happy with the interface it really is important to know it is easy to adapt.
Within the community we have sidebar editors, full screen editors, interactive forms, previews inside the editor and outside the editor, additional multi-line fields and more. Wether you like using the mouse or only the keyboard, autocomplete and in editor tools, WYSIWIG or section editor. Codemirror with its line numbers and advanced toolbars. Others use editable todo lists, modals or open in new/tab window.
Now other plugins or layouts such as streams, two or three story rivers even free floating tiddlers and Mentat, fit other ways of interacting with tiddlywiki such as kanban or even from a timeline or a calendar as the organising principal.
And then there is the standard text area editor, there have over the years being a range of browser based addons that support text area editing, before Codemirror got so advanced I used a tool that allowed me to edit text areas via my editor of choice Notepad++ and someone recently made one to edit tiddlers through VS Code Editor (untested by me).
What device you are using also has a big influence, mobile, touch, tablet or my common use multi-screen desktop. Each has its wants and needs and from what I have seen every one of these has being done.
Many open source editor projects can be brought into tiddlywiki with a little know how, so we are spoilt for choice.
I think this is why you see people sticking to the default mechanisums, because a lot of invisible design work has led to where tiddlywiki is but diverging from it is possible.
I have a project 95% of the way to full window management from the sidebar or an index window now made possible with new parameters on WidgetMessage: tm-open-window and WidgetMessage: tm-open-external-window if there was sufficent interest and demand I could lead a project to develop it.
