How make certain strings fire an action in editor?

[Mat]

For the "editor popup" (i.e really for the TitlePicker, i.e really for the general EditorMagic tool that is supposed to popup in the editor when the user types special strings)...

...someone proposed that typing [[ should automatically convert it into [[]] and put the caret in between for further typing, i.e like in most code editors. This would solve the otherwise difficult problem of knowing if, say; [[this string ends here or here or here and it would make this problem trivial - i.e it ends here]].

So, the generalized idea is to automatically convert a trigger string into trigger+endtrigger and put the caret in between for further typing. Thus, when the system senses that the user just typed the last character of the trigger, it fires off.

How can this be achieved?

The different trigger and end-trigger strings are found in user created tiddlers (tagged, say, "$:/tags/EditorMagic") in the fields titled "trigger" and "trigger-end".

Thank you.

<:-)

[PMario]

Hi Mat,

The CodeMirror editor does this by default.

-m

[Mat]

Thanks. 

When looking for how they implemented it, I note the orginal CodeMirror has "autocompletion" but, based on my limited understanding of js, this does not seem to be what I'm looking for. 

And the TW-plugin has a setting for Auto close tags used in this tiddler... but I can't tell if "auto close tags" is at all what I'm looking for.

I.e where is the code in CodeMirror that adds the closing string, e.g ]] for titles?

Thank you!

<:-)

[PMario]

Hi Mat,

Forget about my post. ... I didn't recognise that you need it for EditorMagic, which is a completely different context.

-mario

[Saq Imtiaz]

Mat, when merged this pull request includes adding the ability for the edit-text widget to fire actions when a user types into the text area:

https://github.com/Jermolene/TiddlyWiki5/pull/4725

This may be something you can use.

[Mat]

OK, thanks anyway. Do you have any idea how this feature could be implemented in TW? 

It is a bit ironical because the whole TitlePicker idea is to identify a string in the edtior (e.g "[[foo") and have the user replace that string (to e.g "[[foobar]]") by clicking some button - but what I need in this question is for the editor to basically do this same thing by itself, i.e to identify a string (e.g "[[") and automatically replace it (with "[[]]")

...

BTW, I just realized that it will not work if [[ is automatically exchanged for, specifically, [[]] because then how will TitlePicker know if it is a complete title or not? And how will it know that the other bracketed titles in the text are complete or not? Instead of the closing brackets, the system should change the [[ into e.g [[| i.e with a temporary pipe character delimiter at the end which, upon picking a title, is properly exchanged for the closing brackets.

Just thinking out loud...

<:-)

[Mat]

Saq Imtiaz wrote:

Mat, when merged this pull request includes adding the ability for the edit-text widget to fire actions when a user types into the text area:

https://github.com/Jermolene/TiddlyWiki5/pull/4725

Oh, wow, talk about coincidence and timing! Thank you Saq!

<:-)

[Saq Imtiaz]

If you want to experiment, you can grab the edit-text widget tiddler from the demo http://tag-picker-kb.tiddlyspot.com/

[Mat]

Saq Imtiaz wrote:

If you want to experiment, you can grab the edit-text widget tiddler from the demo http://tag-picker-kb.tiddlyspot.com/

Thank you! However, my test with it doesn't work:

• From the link you provided, I copied (here) $:/core/modules/widgets/edit-text.js
• I used an action according to a tw.com example:
  <$edit-text tiddler="test1" field="text" inputActions="""<$action-createtiddler />"""/> 
  
• I was now expecting a "New Tiddler" every time I did something in the resulting editor, but nothing seems to happen.

Am I doing something wrong?

Thank you Saq!

<:-)

[Saq Imtiaz]

Right sorry. The exact tiddlers you need from that demo are:

$:/core/modules/editor/engines/framed.js
$:/core/modules/editor/engines/simple.js
$:/core/modules/editor/factory.js
$:/core/modules/widgets/edit.js

Or just import your content into that demo.

Also note that I don't think <$action-createtiddler /> is a valid widget invocation, you will need some parameters.

[Mat]

Haaa! That does work! Thank you.

The question now is how it is adapted for the main tiddler editor... without overwriting shadow tids. Would that be possible if the PR was merged? Is/will there be a way to hook into it (if I'm using the term correctly)?

Also note that I don't think <$action-createtiddler /> is a valid widget invocation, you will need some parameters.

I was also surprised to find that actually...

<:-)

[Saq Imtiaz]

Once the PR is merged, you would need to edit the shadow tiddlers for the editor and add the inputActions= parameter to the edit widget invocation.

You could try raising at PR at that point to add a inputActions={{$:/config/editor/inputActions}} parameter, which would do nothing unless $:/config/editor/inputActions exists.

I honestly wouldn't worry too much about overwriting shadow tiddlers. That is why we have shadow tiddlers, so that we can override them and have the safety to delete and revert to the previous version if need be.

[Mat]

I really appreciate that you reply to all my questions. 

You could try raising at PR at that point to add a inputActions={{$:/config/editor/inputActions}} parameter, which would do nothing unless $:/config/editor/inputActions exists.

I of course don't want to delay the current PR, but it there any other reason for why not to raise this already now?

I honestly wouldn't worry too much about overwriting shadow tiddlers. That is why we have shadow tiddlers, so that we can override them and have the safety to delete and revert to the previous version if need be.

Well, if I did it for myself that'd be OK but I see two potential problems:

1) since this is to be a plugin I don't want to cause problems for people

2) how does the priority of shadow tids actually work? Since it is a plugin, also my template would be a shadow, so which one takes precedence?

 

<:-)

[Saq Imtiaz]

On Saturday, June 27, 2020 at 10:24:05 PM UTC+2, Mat wrote:

I of course don't want to delay the current PR, but it there any other reason for why not to raise this already now?

The PR is about adding keyboard support to the tagpicker and search fields. This addition to the edit widget is an incidental by-product that I suggested in the interests of flexibility. As such, bringing up this change in this PR would be completely off-topic. This PR has nothing to do with the tiddler editor template.

 

Well, if I did it for myself that'd be OK but I see two potential problems:

1) since this is to be a plugin I don't want to cause problems for people

Sooner or later, shadow tiddlers need to be overwritten by plugins to add features. It is rare that two plugins need to overwrite the same plugin and if that problem arises should be dealt with via documentation. No matter how much flexibility we add, for some tweaks shadow tiddler changes will always be needed. That's why they are shadows. Overriding shadows was very normal in the TWC days and rarely an issue. As a plugin writer you check the release notes for each new release of TW. If a shadow you overwrite gets updated, you update the plugin. Happens rarely. Similarly if there already exist popular plugins that overwrite the same shadow, you take that into account. Yes in an ideal world it wouldn't be necessary but practically it sometimes just has to be done.

 

2) how does the priority of shadow tids actually work? Since it is a plugin, also my template would be a shadow, so which one takes precedence?

Plugin shadow tiddlers override core shadows.

[Mat]

Thanks for clarifications. 

<:-)

[Mat]

@Saq - a potential bug in the PR and also problems in getting the exchange of "[[" into "[[]]" to take place:

You get RSOE saying Uncaught TypeError: this.updateDomNodeText is not a function

in the following setup: http://delimit.tiddlyspot.com/

if you open a new tiddler and attempt to edit it.

Note that no modification has been done to the core text editor so it only relies on the four tiddlers you linked to above, and regardless if the inputActions attribute is used anywhere or not.

Other than that, I'd appreciate it if you can try out the failing demo and if you have any thoughts on if I'm doing something wrong or if the route you proposed is not the right one after all.

Thank you Saq!

<:-)

[Saq Imtiaz]

Can you give me step by step instructions to reproduce the bug, as well as your OS and browser version?
I had a quick check and am not getting any errors.

[Mat]

Win 10, Chrome

Ah; it is the title of some tiddler that needs to be edited to cause the error. E.g create a new tiddler the usual way and just attempt to change the title of it.

<:-)

[Saq Imtiaz]

Found it and reported, thanks. It's a typo, udpate instead of update :)

As for your demo, I am not really sure. I mentioned this pull request because it solves the problem of firing actions based on keyboard activity in the text area. Beyond that I am not sure about what you need to do, or how you are approaching the problem overall. 

As for the focus behaviour, I believe the edit widgets don't update their content (value) if they have focus, otherwise it would cause refresh issues with typing.

My personal feeling is that this project is something that would need a lot of JavaScript scaffolding and can't be done using what is available of wiki text and widgets... which I know is not what you want to hear and I hope you prove me wrong!

[Mat]

Saq Imtiaz wrote:

My personal feeling is that this project is something that would need a lot of JavaScript scaffolding and can't be done using what is available of wiki text and widgets... which I know is not what you want to hear and I hope you prove me wrong!

My personal ambition with EditorMagic, as a mere WikiText coder, is to make a prototype good enough to convey the concept properly. TW itself is probably to crude to have it work smoothly - so my hope is that some of the real coders will say "Hey, EditorMagic is actually really useful if I just exchange components X and Y." I believe the concept overall has the potential to really enhance TW usability.

So, yeah, I also think it would need a lot of JS. Luckily some of you big boys are helping with the absolutely critical parts, like making the popup show at caret position, and I'm really grateful for it.

<:-)

[Saq Imtiaz]

Mat: here is an alternative approach to consider.

- a button or keyboard shortcut in the editor that creates a popup at the caret position

- an input field in the popup where you start typing whatever you want autocompleted

- now its easy to know where the string starts and ends

- all your other autocomplete logic and UI can be in the same popup underneath the input field or to the side

- once completed, hitting enter inserts that text at the caret position.

[Saq Imtiaz]

PS: If I was going to try and do this with just wikitext, that is probably where I would start.

[Mat]

Saq - whoaa! - that is a really interesting and very clever approach! 

I will need some time to mull over it and envision the workflow. I haven't quite given up on finding a regexp to identify start+end but maybe I should.

Thank you!!!

<:-)