Can we access the 'selection' in the WidgetMessage: tm-edit-text-operation

Two major improvements:

First, I overhauled the logic to reduce the need to change the javascript and increase flexibility. Markup menu items are basically handled by two logic blocks, one for line-based markups (e.g. bold, italics, etc…) and block-based markups (e.g. mono-block). If you want to add options, you only need to clone and adjust one of the existing context menu tiddlers, ensuring to specify (as fields) the markup-prefix and markup-suffix, and you are off to the races. This approach works for macros also, such as Stobot’s Sticky. This means you shouldn’t need to touch the $:/plugins/ahanniga/context-menu/ContextListener.js for anything to do with styling and simple macros…

Second, I included a conditional logic handler, which means I can package a bunch of context menu items that are relevant to me but not to others. If the dependent plugins are not loaded, the matching context menu items are going to be hidden. For example, I can now package a menu entry for Stobot’s Sticky as well as one from JanJo’s ToDo (by popular demand @arunnbabu81 !), realizing full well that most people won’t have both. The correct menu entry will be displayed. In my setup, I also have the Mark highlighter, which will show up if you also have it loaded.

with Sticky:

same plugin with ToDo instead, and Highlight:

plugin_fastfreddy_ContextMenuAddin_v0.0.6.json (18.1 KB)

4 Likes
case "tm-todos":
if (selection.trim().length > 0) {$tw.wiki.setText(targ,"text",null,text.replace(selection,"<<ToDo \""+selection+"\" "" ""\>>"));}

This was my code which was not working.

Edit: I will try out the new json you uploaded.
Sorry for the delay. I had to debug my wiki (Still not over). The context menu was not showing up in my main wiki due to some conflict with context menu plug in and some of my modifications or multicolumn plug in. Have to find out the cause. So all my context menu experiments were in a newly created wiki.

most likely missing a few escape characters (untested):

[quote=“arunnbabu81, post:47, topic:4558”]

case "tm-todos":
if (selection.trim().length > 0) {$tw.wiki.setText(targ,"text",null,text.replace(selection,"<<ToDo \""+selection+"\" \"\" \"\">>"));}

however you should find the version posted above to include what you need.

1 Like

@fastfreddy Thank you so much. It works now. Both monoblocks and ToDo.
I think it is easier to hack it now to include frequently used macros and formatting by other users.

I have decided to package as a plugin properly. Not fully tested, if you note any issues, please circle back

Context menu selection add-in

2 Likes

I think this discussion should be split somewhere so that the new add on gets a seperate discussion thread.

Just some ideas which came to my mind…might be beyond the scope of this plug in …how about the selected text being made the content of the new tiddler instead of the title and leave a link or transclusion in the parent tiddler…can the browser dialogue box be used to name the new tiddler using the mechanism used for renaming of nodes in streams.

Hi @fastfreddy,
you did a great job there,
alas the highlight feature is not working yet in the demo.

A feature I would long for would be an edit field containing the selected text at the top of the context-box. This could be a good way to cure typos without switching into edit mode.
Another nice feature would be the possibilty to insert links to external sites in the contextmenu.

released 0.0.9 which addresses the highlight issue and other minor improvements; not too sure how to go about the other ideas expressed here. Will reflect on them…

I like this idea @TW_Tones ; maybe I can provide visual cues with the CSS styles (e.g. disabling the options when the rendered text string isn’t found in the raw, etc…)

ok @TW_Tones, released 0.1.0 which provides visual cues when the number of matches is greater than 1 (along with a number of matches in parentheses), and disables markup options when the selection can’t be found in the underlying wikitext.

I found some :

  • Highlighting a text, then highlighting again delete the selected text
  • Quote doesnt insert newline and thus doesnt work
  • Sometimes the text in the context menu is red and there are some counters ? Not sure if it’s intended or not

I like the idea a lot, thanks for sharing your work !

@telumire

re: highlighting twice; this is due to the simple search and replace operation that mangles the markup; known limitation with no immediate plans to fix (not sure how to handle those complex situations, similar in complexity to clearing the markup of the selection requested by @arunnbabu81 ).

re: quote; fixed in 0.1.2; please let me know if that still doesn’t work for you

re: counters: yes see above, at the request of @TW_Tones, there are now visual clues when the text selection has multiple matches in the raw wikitext, suggesting that many replacements will be made. Similarly, if there are no matches (say the text is actually a transclusion from another), the options will be disabled to inform the user no replacement can be made.

I was thinking of a function similar to the functionality of the excise editor toolbar button

yes, but I need to know the title at the moment the user clicks, in order to create the link.

@ahanniga @saqimtiaz : how would you recommend tweaking the $:/plugins/ahanniga/context-menu/ContextListener.js widget (and/or the current anchor of <$contextMenu> in $:/plugins/ahanniga/context-menu/view-template) for the context menu to work within Streams nodes?

I have tried a few different things (e.g. fetching data-node-title instead of data-tiddler-title and anchoring the widget in $:/plugins/sq/streams/templates/stream-row-template just below {{||$:/plugins/sq/streams/editor-template}}, but without success so far.

It seems the data-node-titleattribute returns null even if it appears to be well defined in $:/plugins/sq/streams/templates/stream-row-template everywhere.

Are there better approaches?

Cheers!

The context menu with the typographical applications is really good @fastfreddy and others who this is built on. Some thoughts;

  • This is almost a WYSIWYG editor
  • This is a great way to reformat content pasted from elsewhere

Future enhancements

  • Allow you to select one of the multiple instances to apply a change to rather than all.
  • Reversable edits, as works in editor Toolbar, select bold, click bold to remove?

@fastfreddy can search and replace function be added to the context menu - for that also we need an option to input the replacement text. Just a suggestion.

This thread seems to have diverged pretty far from its title and is thus hard to follow and provide assistance. I suggest starting a new thread for your plugin and posting a summary of the problem as relates to Streams.

Hi @TW_Tones ;

  • Allow you to select one of the multiple instances to apply a change to rather than all.

I am not sure that it is possible. There is no information on the right-click event that indicates which of instances has been selected. The two options are either A) replace the first match, or B) replace all of the matches.
Option A can lead to very weird behaviours where you apply it to some text and the formatting is applied to a different instance of that string.

  • Reversable edits, as works in editor Toolbar, select bold, click bold to remove?

I am also not sure that is possible. It may be possible to toggle simple markups (by simple, I mean immediately next to the string, e.g. ‘‘mystring’’), which I intend to play around with, but as outlined above, it is hard to get smarter than that.

For example, what if the raw text actually renders as I am liking mystring very much… To the search and replace function, this may look like mystring is surrounded by bold markups whereas it isn’t; what search and replace regular expressions would find is the end of the first string’s bolding, and the beginning of the next string’s bolding.

Similarly, if you have bold and italics, and toggling off italics would only work well if the markup for italics are closest to the string. I think efforts in that direction are bound to mangle markup and leave users upset.

I remain open-minded if others have good implementation ideas. There seems to be no shortage of wish list ideas, but I am not sure they are realistically implementable…