Ideas to improve wrap-selection and wrap-lines operations (tm-edit-text-operation)

[vilc]

I have some ideas on how the wrap-selection and wrap-lines operations used by many editor toolbar buttons.

1. wrap-selection: ignore surrounding spaces (or all whitespace).
In Edge/Windows (and presumably also all Chrome-based browsers on Windows) double clicking a word selects it with the trailing space. With how wrap-selection works now, applying “bold” or “linkify” wraps the word and the trailing space with the markup, e.g. ''word '', [[word ]]. This is not tragic for stylistic markup like bold (only the code looks ugly), but it’s problematic for links and transclusions of course.

Android browsers select just the word upon double click. I haven’t tested on other platforms yet. But I think it is extremely rare that one wants to apply some formatting or linkifying to a word or text including the surrounding spaces. So this should be beneficial also in situation where one accidentally selects the word and surrounding spaces, regardless of the platform.

2. wrap-selection: undo markup if selection surrounded by markup
If a following snippet is selected and the linkify button is used, it is transformed to [[[[word]]]].
Only if the whole markup is selected will it be transformed to word.

I think it would be more practical if the markup was removed also if it is adjacent to the selection. This would allow to double click (which doesn’t select the markup) a marked-up word and remove markup with one click.

3. wrap-lines: undo markup if selection includes markup or includes marked-up lines

Undoing of block markup works different than of line formatting. In order to remove the markup, all lines have to be selected in entirety, e.g.:

I think it would be more practical if the markup was removed also if the markup is selected, e.g.:

And if only a partial selection inside the block is made, e.g.:

---

Do you also find these changes would be beneficial for user experience?
Could they collide with uses of these operations other than editor toolbar buttons?
Would it be feasible to include these changes in the core? From how the wrap-lines undoes the formatting I presume the operation can be “aware” of the surroundings of the selection, not just the selection itself.

[Scott_Sauyet]

I’m not really in the target audience for these changes, as I rarely use the editor buttons or even their related keystrokes; I tend to type the markup directly. Only CTL-E and ALT-P are regular.

@vilc

Do you also find these changes would be beneficial for user experience?

Absolutely. I hate the trailing space various editors include on selection. I had never stopped to realize that it’s a Webkit thing.,

@vilc

Could they collide with uses of these operations other than editor toolbar buttons?

It’s unclear to me. I haven’t dug into these to see how they work.

@vilc

Would it be feasible to include these changes in the core?

Again, I haven’t really looked, but it certainly sounds feasible.

[jeremyruston]

Hi @vilc I would support getting the improvements you’ve listed into the core. It’s very hard to determine the impact of non-backwards compatible changes (eg trimming whitespace before linkify), but I think it’s worth trying to iron these niggles out.

[duarte.framos]

Definitely welcome additions, they’ve been on my wishlist for quite a while. Trailing spaces are an annoyance.

[vilc]

@Scott_Sauyet

I had never stopped to realize that it’s a Webkit thing

After some more testing, I suspect it’s a Windows thing*. Selecting the trailing space upon double click happens on Firefox and various Chrome derivatives (Vivaldi, Edge) on Windows, but it doesn’t happen on any browser on Android, Firefox/Linux, or Safari/macOS.

But the proposed changes cover also other situations that would happen on any browser/OS.

@Scott_Sauyet

I rarely use the editor buttons or even their related keystrokes; I tend to type the markup directly.

I usually type the markup when creating new content, but when editing, I find the toolbar buttons handy. And they would be certainly more handy if they worked better with existing double-click word selection mechanisms.

My most recent motivation for this topic is the Recipes community edition and making markup in it more inviting to newcomers.

---

* Edit: it’s definitely a Windows, or rather, Microsoft invention, as it’s present e.g. in default Windows notepad or Word (on Mac as well).

[Scott_Sauyet]

@vilc

[I]t’s definitely a Windows, or rather, Microsoft invention, as it’s present e.g. in default Windows notepad or Word (on Mac as well).

Why does this not surprise me? It’s definitely an annoyance, I must say.

I use Windows all day at work. (I’m hopeful that the Mac will be fixed next week!). And I just replaced my Linux laptop at home with a Windows box, and haven’t yet gotten around to adding an Ubuntu dual-boot. So I’m stuck in Windows world except on my phone. Uggh!

[duarte.framos]

@duarte.framos

been

I use Firefox under windows and it is the same behavior, so not a Webkit exclusive thing.
Some web editors already work around this, like the ones over at the Stack Exchange sites like Ask a Question - Portuguese Language Stack Exchange

[TW_Tones]

@vilc I think your argument we need improvement is a winner. I am not sure how best to address them yet. Personallyy I like being able to select a block and apply block formatting but I would also like to select and reverse it, this is not easy as it stands because of the issues you raise.

I use the keyboard a lot when writing and use the mouse and editor toolbar when improving appearance or editing. This is even more important to me because I have multiple wikis open at a time and first and foremostt, navigate between them with the mouse. I want to minimise how often I am forced to resort to the keyboard, even if I also like to use the keyboard and not get forced to use the mouse.

I would urge keeping an open mind to a solution here because we could not only fix the problems but enhance functionality.

• I think we need to keep the solution within tiddlywiki and not introduce too many changes to the default browser or OS behaviours.
• perhaps see if the behaviour is similar in the new code mirror 6
• Also look at the shortcut keys your Operating system or browser supports for text editing because there are multiple ways to extend a selection, perhaps we cn make these easier to use?
• If we can make the operations that occur on selected text a little smarter we can sole many of these issues inside the editor toolbar button.
  • For example use trim before applying the [[word ]] but leave the space alone [[word]] (dont remove it from the text).
  • what if in the buttons action widgets we could ask to expand selection to line/sentence etc… ? In a way this is already happening for wrap-lines

The best idea that comes to mind so far is both a keyboard and mouse method to expand or collapse a selection in a way that is wiki text and tiddlywiki script aware. eg

• select word expand to [[word]]
• expand to something " quote with [[word]] in it
  *paragraphs expand to sentence
• expand to paragraph
• or select word expand to <<word param>>

But with more awareness we could expand to select the widget the content is in etc… See here as an example VSCode Keyboard Shortcut: Shrink and Expand Text Selection. But a mouse version, with single key press would be great. eg double-click to select, ctrl-click selection to expand.

I wonder if there are browser addons that can help?

[pmario]

I think all your suggestions make sense. – This behaviour also bothers me quite a bit, but I did not take the time to address it.

---

I did just implement a proof of concept (POC), that allows us to define a new “trim” parameter for the tm-edit-text-operation message

It will convert the selection ` word ` into ''word'' and it will leave leading and trailing spaces alone.

---

The wrap-section - $param has additional parameters prefix, suffix and trim now

Eg: The bold button code could looks like this

title: $:/core/ui/EditorToolbar/bold

<$action-sendmessage
    $message="tm-edit-text-operation"
    $param="wrap-selection"
    prefix="''"
    suffix="''"
    trim="both"  <!-- no (default), both, start, end - are possible -->
/>

Screencast

---

It has a slight improvement for the next “edge case” you describe but it can not handle it entirely well.

If a following snippet is selected and the linkify button is used, it is transformed to [[[[word]]]].

I think it can be improved.

[pmario]

I think is this particular case, the term “trim” is not right, since it does not really trim the spaces. It removes leading and trailing space from the selection and leaves the spaces alone.

May be trimSelection would be a better one.

[pmario]

@vilc

2. wrap-selection: undo markup if selection surrounded by markup
If a following snippet is selected and the linkify button is used, it is transformed to [[[[word]]]].

Seems to work now too (easier as expected) It does add the extra 2 braces, but they are very easy to remove now. Which was not the case with the current TW version

[pmario]

In a view minutes a preview should be available at: Add trimSelection parameter to text editor by pmario · Pull Request #7944 · Jermolene/TiddlyWiki5 · GitHub

The PR is only a draft, so it can be discussed here or at github.
Please only post here or at GH. Do not post 2 times the same thing.

---

It would be nice, if somebody could test this with CM6 - CM5 seems to work as expected

[pmario]

Hi folks,

The PR #7944 has been merged a view minutes ago. Please have a look at the TW-prerelease.

Important

• The TW prerelease contains the codemirror plugin - Please test
• Also test with a local version where the codemirror is disabled

If you find any problems with your own plugins please let us know.

• The new behaviour is described at: WidgetMessage: tm-edit-text-operation
• See: wrap-selection parameter trimSelection – which is set to yes by default for
  • Bold, Italic, Strikethrough, Underline, Superscript, Subscript, Monospaced, [[]] and {{}}

If you want to test your own configuration follow: How to create dynamic editor toolbar buttons, which lets you easily create a new edit-toolbar-button to play with.

have fun!
Mario

[vilc]

As far as I have tested it seems to work well for all the mentioned editor toolbar buttons.
The new behavior is not applied to the “create wikitext link” button. Is it intentionaly so? If technically possible, I think this button should also trim selection by default.

---

@pmario

• The TW prerelease contains the codemirror plugin - Please test
• Also test with a local version where the codemirror is disabled

Just a side note, it is also possible to test without CodeMirror using the empty prerelease under https://tiddlywiki.com/prerelease/empty.html

[pmario]

@vilc

The new behavior is not applied to the “create wikitext link” button.

hmmm. That’s a different “text operation” - The PR changed the wrap-selection text operation.

Creating the wiki-links is make-link and it uses: $:/core/ui/EditorToolbar/link-dropdown

I did not consider that one at all. Probably because I do not use it that often. I’ll have to have a closer look, when I’ve time.

Thanks for testing.
-m