The single biggest improvement in my usage of TiddlyWiki recently, in part driven by experience of other tools, is auto complete of square bracket wikilinks.
e.g. start typing [[Some L and it presents a list of tiddler titles that you can choose from using arrows and then hit enter and it completes as [[Some Link]].
I use Edit-CompText by snowgoon88 (I’ve sent an invite by email from the forum here, so hopefully they see this).
This would be part of any Edition I ever put together, because it makes the power of tiddlers that much more obvious.
I’d love to see this as part of a Commons, and in general see about how to get it into Core.
Has this come up before? What’s the path to Core for any plugin in particular? For that matter, the process of kicking plugins out of core?
Agree whole heartedly that this one and relink (at least part of it) are such core-esque components that I’d love to see them baked into the core. My 2 cents.
Note that there has been discussion that would have led to core support for autocomplete and other related solutions, but it eventually petered out due to a lack of feedback on architectural decisions that needed to be made.
It would be great if someone wanted to pick that up again.
Having worked on the Edit-CompText plugin (I am one of the collaborators on the Edit-CompText repository) as well as having prototyped alternative implementations in TW, from my perspective getting autocomplete support in the core would look something like this:
Introduce support in the core for positioning popups at the caret position in text area based editors. There is a small third party library that can be integrated for this purpose. The edit-comptext plugin uses an earlier version of the same library.
Extend the editors available in TiddlyWiki (Framed and CodeMirror) to provide access to the caret position in actions triggered from inside or outside the editor.
Implement an autocomplete solution that can be customized via wikitext and supports both the Framed and CodeMirror editor.
Having #1 and #2 in place would also open the door to other related solutions like, popup menus triggered in the editor as the user types.
Thanks for the detailed write up @saqimtiaz! Super great to have a list of what needs to happen.
This feels like the only thing on the list that could get a pass. CodeMirror itself is a third party library that will shift over time. Or the reverse, make it work only with CM. But I’m guessing that the core, plain editor support will be more desirable.
Is Framed the name for the core TiddlyWiki editor? I couldn’t easily find any references to it.
Getting the code for the Edit-CompText plugin in compliance with core standards would require a complete re-write anyway, at which point adding CodeMirror support is trivial since the library itself provides a method to return the caret coordinates. Literally less than 5 lines of code. However, without that rewrite of Edit-CompText it would be a difficult to integrate with CodeMirror.
The great thing about using core mechanisms for popups etc is that they work in CodeMirror as well without any extra effort and would serve as future proofing for working with any new editors that might be implemented. So CodeMirror support would be a natural outcome of a well written autocomplete implementation, rather than something that would need bespoke extra work.
We have a concept of editor engines in TiddlyWiki that wrap the underlying mechanism of the editor in a standardized interface. This standardization is why we can write implementations for editor toolbar buttons and even autocomplete that can work for all editor engines without any significant extra effort.
There are two engines that ship with the core: Simple and Framed, and then we have CodeMirror via a core plugin. The difference between Simple and Framed is that the Framed engine supports toolbar buttons, popups etc and under the covers uses an iframe. This is the default editor for the tiddler body, where as the Simple Engine is used for the input fields for the tiddler title for example.
I understand that a complete rewrite of our autocompletion plugin is in order so that it could be considered as joining the “core”. In particular, I quote
1 it cannot be customized without editing JSON
2 it cannot work with the CodeMirror editor and nor can it easily be extended to do so.
3 it does not use TW mechanisms for creating and navigating popups which makes them harder to customize.
Regarding points 1 and 3, I could find some time to comply with them if I have some pointers on the “proper TW way” to do that. So, my questions would be : where do I find some info on these subjects ?
I have no idea if any work has been done in this direction in the past year, but if we are still gathering requirements, I just starting using the wonderful Edit-Comp Text. It is already speeding me up, but I would love it if this also handled [[display text|Some L and searched for matches on “Some L”, but possibly also “display” and “text”.
Another thing: it would be nice if {{ and <$ were triggers, the first searching all the non-system- and secondarily all system-tiddlers, the second searching all widget names, and I guess offering macro names for <<, too.
Just a heads-up in case you haven’t come across it yet: you may be interested in Maurycy’s new Auto Complete plugin! It doesn’t come preloaded with all your wishlist items, but it does let you configure whatever triggers and autocompletion behavior you like via a pretty simple UI.
This is a much better alternative, it is up to date, maintained, very flexible, customizable in many ways! supports both CodeMirror and native editor, …
So, I would highly recommend @Maurycy Auto Complete.
