The various tm-edit-text-operation actions allow us to perform a number of different transformations of the selection. We can also add additional actions to do other things. This is used for defining editor toolbar buttons.
I would like to pass the selected text to one of these other non tm-edit-text-operations but there is no documented variable or otherwise to access the selected text.
Can anyone determine if there is an undocumented variable or other method and if not perhaps I will raise an issue to include one?
The editor toolbar buttons contain one or more actions like any other actions you can trigger from a button.
I have used this to extend or build more sopisticated buttons.
We can set a field or template to the selection then use that, but it would be simpler if a variable was available was set to the selected text. The fact is the text operation actions actualy must have access to this value, most likely a variable already, to work.
I dont have the skills to read the text operation actions code to see if there is a variable available or if not see if one can be surfaced.
This feature would allow me to simplify and share code when developing solutions based on plain language in topics I posted recently.
this includes parsing the selected text with filters and responding with variouse actions.
Advanced functionality: to also make buttons and keyboard shortcuts outside the editor that have access to the current read only selection would be useful.
Hi @TW_Tones I think you are asking if within the edit text widget we can make the current selection available as a variable.
The technical answer is that it is not practical at the moment because it would cause the contents of the edit widget to fully refreshed every time the selection changes, which would have a performance impact. That is why the ‘tm-edit-text-operation’ message works the way that it does: it allows authors to manipulate the selected text without needing to know its contents.
An alternative approach that might work would be to add a new operation for ‘tm-edit-text-operation’ that takes a parameter specifying a filter that is used to manipulate the selection (and also optionally the text before and after the selection). That would make it possible to make edit toolbar buttons that did transformations like “convert to uppercase”.
Yes. Othe toolbar buttons I have created that could use this is to sort the selected lines a-z and z-a. Currently I am having difficulty making them reliable.
Think of the possibilities of having a global core variable that contains the text selection; any widget or macro or filter could use this information and do something useful with it
I dont know if it helps but what I did to avoid issues when manipulating text like this is to use filtered transclusion on the attributes of the tm-edit-text-operation widgets, e.g to comment some code :
@jeremyruston: With “every time the selection changes” do you mean during the process of selecting something? Like while I’m dragging the mouse to select a couple of words, the widget would update a bunch of times while the selection expands.
Or would it only update once after releasing the mouse button to finish the selection process? I can’t imagine that this would have a performance impact since it’s done only once. So I guess you mean the former…
My use case is more about having access to the text selection in view mode, and be able to use it to do interesting things such as creating a new tiddler with that text as its title…
@fastfreddy Maybe you want the Dynannotate plugin?
Code :
<$button>
<$action-createtiddler $basetitle={{selection}} tags="annotation">
<$action-navigate $to=<<createTiddler-title>>/>
</$action-createtiddler>
Create tiddler from selection
</$button>
<$dynannotate selection="selection">
Lorem ipsum dolor sit amet [..]
EDIT: It may also be possible to do this with the eventcatcherwidget but I’m not sure how
EDIT2: Seems like the eventcatcher doesnt work with the select event
Just to be clear, if the widget were only refreshed when the button triggering it was pressed would be sufficient, but I don’t know how practical that is.
@telumire seems to have the view template version working with $dynannotate on the view template, using the selection attribute, and a tiddler.
Thanks for all the great suggestions everyone! I was able to use most of them to grab bits and pieces of code (like the plumber I am) and now have solution that is simple and works really well, from view mode. In the end, I found Dynannotate to be a bit of and overkill, and I instead based the solution off the context menu plugin.
I have modified a few things:
1- disable the check for selection (initially, the plugin deliberately does not work if there is text selected);
2- inserted a with a check for the control key (inspired by @saqimtiaz 's link context menu plugin). This way, you can still access the browser’s context menu for selections, if you wish, by pressing the control key. I may choose to inverse the logic, but for now, this is my preference;
3- added an option on the context menu that 1) creates a new tiddler from the text selection and 2) replaces the selection (text search and replace) with a link to the new tiddler, from view mode (this I thought would be much harded than it ended up being, inspired by this search and replace plugin)
(this code goes in $:/plugins/ahanniga/context-menu/ContextListener.js, but you need one more simple tiddler for the new menu item.)
case "tm-new-tiddler":
this.dispatchEvent({ type: "tm-new-tiddler", paramObject: {title: ""+selection+""}});
$tw.wiki.setText(targ,"text",null,text.replace(selection,"[["+selection+"]]"));
break;
I’ll continue to play around but this seems to fit my needs.
One shortcoming noted so far is if the raw text has a line break that is not visible in view mode (or any other fancy wikitext rendering), the search&replace function will not find the selection in the text. I can probably live with that.
Thanks it works well @fastfreddy, I had not used the context menu plugin before, its great. Such a menu could be the solution here Has anyone found a solution to title and button overflow on tiddlers? and expect it may work well with MCL Multi-column layout whose weakness in my view is titles/button competition for space.
Now also the answer to this topic is included. Thanks.