Support for positioning popups at the caret position in editors

[saqimtiaz]

It would be desirable to have core support for positioning a popup at the caret position in the tiddler editor. This would make it possible to implement autocompletion solutions that work across all the editor engines (simple, framed, codemirror), something that is currently lacking.

It is proposed to do so by:

• extending each editor engine with a method getCaretPosition()
• providing a variable tv-popup-coords to the inputActions fired by the <$edit-text/codemirror> widget on every input event in the editor
  • this variable can be used with <$action-popup> to display a popup at the caret position.

The codemirror library already provides a cm.cursorCoords() method that can provide the caret co-ordinates.

For the simple and framed engine, the textarea-caret-position library can be used to get the caret co-ordinates. This is the library used by the edit-comptext plugin, works well and is 5kb uncompressed and 2kb minified.

[Jermolene]

Hi @saqimtiaz great, that would certainly be very handy.

[saqimtiaz]

@Jermolene do we have any guidelines or best practices to follow when including 3rd party libraries like the textarea-caret-position library in the core?

I will work on a PR as time allows.

[Jermolene]

@Jermolene do we have any guidelines or best practices to follow when including 3rd party libraries like the textarea-caret-position library in the core?

I will work on a PR as time allows.

Thanks @saqimtiaz.

My preferred approach is to put the 3rd party files in a files subdirectory with a tiddlywiki.files file to pull the required data in. I try to include the license file too if possible. I try not to modify the 3rd party files, using tiddlywiki.files to add a prefix/suffix to JS libraries to make them work with our module loader.

We don't use npm to manage dependencies, which I think is still a useful approach as it means that our users don't need to understand npm in order to use TiddlyWiki. In some cases, under Node.js, we just do a require("aws") and expect the user to have npm installed the right thing, but I think that's only appropriate for certain special cases where understanding npm arcanery is not so unreasonable.

[saqimtiaz]

Thank you @Jermolene.

In case anyone else has the same question regarding 3rd party libraries and finds their way here, there is a good example in the Diff Match Patch library: https://github.com/Jermolene/TiddlyWiki5/tree/master/core/modules/utils/diff-match-patch

[Jermolene]

In case anyone else has the same question regarding 3rd party libraries and finds their way here, there is a good example in the Diff Match Patch library: https://github.com/Jermolene/TiddlyWiki5/tree/master/core/modules/utils/diff-match-patch

Yes indeed, searching the code for tiddlywiki.files turns up several dozen 3rd party library integrations, mostly in plugins, but the other one in the core is the base64-utf8 conversion library: https://github.com/Jermolene/TiddlyWiki5/tree/master/core/modules/utils/base64-utf8

[pmario]

The good think with the tiddlywiki.files approach is, that you can add the compressed and uncompressed library-versions to the folder. Plus license and a readme, if you want, without bloating the core itself.

• The documented version can be used to have a look at the code, without the need to search for it.
• The compressed version keeps the footprint for the core low.

[saqimtiaz]

I have been giving this some more thought and what needs more consideration is making the caret co-ordinates available to actions. We can divide this into actions triggered inside the editor (via editor toolbar buttons or other editor tools), and actions triggered outside the editor. I would really appreciate input on the second of these, actions triggered outside the editor widget.

Actions triggered inside the editor widget
If the actions are invoked via the inputActions attribute of <$edit-text> or via a toolbar button, we can make the tv-popup-coords variable available. Furthermore, we could implement a tm-editor-popup message handled by <$edit-text> that positions a popup at the caret.

Actions triggered outside the editor widget
An example of this use case is the popup created with the new feature that allows dropping an image on the editor to import it. It would be desirable to position that vertically at the caret position. That popup is created via <$action-popup> which is triggered by a <$dropzone> widget which is wrapped around the <$edit-text> widget. The <$dropzone> widget has no way to get the caret co-ordinates and position the popup at the caret within the editor. It is ignorant of the <$edit-text> widget that the drop came from.

Suggestion 1 would be to have two new attributes for <$edit-text>:

• caretPopup : the state title of a popup to be positioned at the caret position
• caretPopupTitle : a tiddler title which when it changes, triggers the popup specified by caretPopup to be shown.

Suggestion 2 is a more generic version of the above idea, two new attributes for <$edit-text>

• triggerActions : actions triggered by the <$edit-text> widget when the triggerActionsTitle tiddler changes.
• triggerActionsTitle : a tiddler title that when it changes, triggers the actions specified by triggerActions. The benefit of this approach over the previous one is that it can be useful in other scenarios, and will allow options like using action-popup to create a floating popup that needs to be dismissed explicitly.

Can we think of a more elegant way to go about this?

One way to avoid the issue altogether would have been to have <$edit-text> create a <$dropzone> widget programmatically inside it and wrap it around the editor DOM node. Then the approaches described for actions triggered inside the editor widget would have been viable. However, I intentionally avoided that approach to allow for greater transparency and hackability for end users, and to avoid more blackbox behaviour. Not to mention that there are sure to be other use cases where the same need will be present.

Another option is having <$edit-text> always update and save its caret position in a specified tiddler. However this would happen on every keystroke and there are many events that can change the caret position. Getting the caret position on demand seems the better way to go.

[twMat]

FWIW: Did you consider that if one clicks outside of the editor, e.g to drag'n drop a link into the editor, the focus from the editor is lost and so is the caret position. However, DnD'ing the link into the editor does triggers a caret at the hovered position, which is where the dropped link is inserted, so there is already some kind of position detection taking place.
[No need to reply to this comment, if it is not relevant.]

[arunnbabu81]

@saqimtiaz Any updates regarding this discussion and implementation of UX described here