When double-clicking, please do NOT select tailing whitespaces after words

[grandsong]

Do you want to request a feature or report a bug?

Feature

What's the current behavior?

Just take the official example (playground) as ... an example.

This is editable rich text, much better than a <textarea>!

If I click anywhere in the word "editable", then press ctrl + →, the cursor will move to the end of the word.

That's nice. Exactly what I want.

However, if I press ctrl + shift + →, the cursor will move over the white space after the word and stop at the beginning of the next word "rich".

So the selection includes that whitespace.

The same thing happens if I double-click the word.

If I want to do something only with the word "editable", excluding that whitespace, I will have to press shift + ← to move the cursor backward and shrink the selection.

Something like what?

Well, I may request or develop for a feature that when I press shift + ' (equivalent to character ") or shift + 9 (equivalent to character (), a pair of double quotation marks or parentheses will enclose the selected word(s).

This feature, which I like very much, is common in modern code editors.

You can imagine how annoying if I have to deal with the unwanted tailing whitespaces in the selection before I enjoy such convenient enclosing.

---

Slate: eh, latest?
Browser: Chrome & Firefox
OS:Windows 7

What's the proposed behavior?

I propose that when pressing ctrl + shift + → or double-clicking, the selection will expand to the end of the word, before the whitespace after that word.

PS

I mentioned the behavior of ctrl + → because it differs from those in most editors, including Microsoft word as well as the contentEditable = "true" mode in browsers.

I'm Chinese, not an English native. I'm not sure if the traditional behaviors were purposely designed so.

But I bet there probably is a good reason for Slate to have chosen this different way. And personally I prefer the latter.

Or, more smartly...

I guess a major reason for traditional behaviors is that people will often cut & paste (or drag & drop) in order to move selected word(s) to another position.

In this case, a tailing whitespace needs to be included in the selection.

Here, I have an idea that can resolve the conflict between the two use cases.

1. When you select words, no tailing whitespaces are included.
2. Then, when you cut the selection, and if there are both a leading whitespace and a tailing whitespace around it, expand the selection to the tailing whitespace before executing that "cut" command.

[cs-intellineers]

This seems not to happen on Linux (Manjaro) Chrome. I am unable to reproduce this behavior.

I click once into "editable":

• ctrl + → moves the cursor to the end of "editable"
  (resulting in something like This is editable| rich text, ... where the "|" symbolizes the cursor)
• ctrl + shift + → extends the selection from the point I clicked in to the end of editable.
  (resulting in something like This is ed[itable] rich text, ... where the brackets stand for the selection)

Double clicking selects only the word and no trailing white spaces (This is [editable] rich text, ...).

I believe (at least on Manjaro) this works like you described it should work.

[grandsong]

I believe (at least on Manjaro) this works like you described it should work.

Yes, but unfortunately this is not the case on Windows, on which I work.

I guess Slate uses the built-in functionality provided by the browsers which subtly vary on different OSes?

I have checked contentEditable = "true" mode of my Firefox and its ctrl + → behavior is to move cursor to position after the tailing whitespace. There is consistency among all its behaviors.

Slate seems to have purposely overridden the ctrl + → behavior only, so far. (Someone should have written those codes. I hope he/she can read this issue.)

Maybe Slate is just on the half way toward to another consistency where all behaviors will exclude tailing whitespaces on Windows?

[toymil]

I've looked into this in the past and convinced myself this is just the way Windows is.

However, I was wrong, you CAN change this in browsers (and some other apps don't behave in this way either, so it's probably not controlled by Windows, just some "platform convention"?).
For Firefox, set layout.word_select.eat_space_to_next_word to false in about:config; for Chrome, see Sources.1 (I don't have Chrome installed so I can't test).

Sources:

1. https://superuser.com/a/1623999
2. https://kb.mozillazine.org/Layout.word_select.eat_space_to_next_word

[grandsong]

I've looked into this in the past and convinced myself this is just the way Windows is.

However, I was wrong, you CAN change this in browsers (and some other apps don't behave in this way either, so it's probably not controlled by Windows, just some "platform convention"?). For Firefox, set layout.word_select.eat_space_to_next_word to false in about:config; for Chrome, see Sources.1 (I don't have Chrome installed so I can't test).

Sources:

1. https://superuser.com/a/1623999

2. https://kb.mozillazine.org/Layout.word_select.eat_space_to_next_word

Thanks. It is nice to change that behavior of Firefox's.