This behavior makes some amount of sense on word processors; when you want to delete, or cut, or move a word, you often want to include the space after the word; at least, that's the justification behind it. But it makes no sense whatsoever on read-only content, most especially on browsers. Since there isn't a system-wide solution, browsers are what I will focus on.
Firefox
This is easy to fix in Firefox: it has the layout.word_select.eat_space_to_next_word setting. Go to about:config, search for this setting and set it to false.
Chrome / other Chromium browsers / Electron apps
Unfortunately, there isn't an easy fix for Chrome and other Chromium browsers. The trick mentioned in three previous answers (double click, but on the second click, move the cursor slightly) generally works in Chromium browsers. My problem with that was:
- you need to do it every time if you never want the trailing space
- It works with clicking mouse buttons or clicking touchpad buttons, but not with "tapping" touchpad, as double tapping and moving on touchpad would simulate click and drag instead.
To help with 1., wrote the following workaround on AutoHotkey:
#If WinActive("ahk_class Chrome_WidgetWin_1")
~LButton::
if (A_TimeSincePriorHotkey < 400) and (A_TimeSincePriorHotkey <> -1)
MouseMove, 1, 0, 0, R
return
#If
If you double click (i.e. within 400 ms) on a Chromium browser, it moves the cursor by one pixel before you release the mouse key, so that only the word is selected.
This works fine if you use a mouse, or if you actually forcefully click twice on the touchpad (or buttons if it has those). But it doesn't work well if you double tap on the touchpad. Presumably this is because, when you first tap the touchpad, it doesn't immediately send the click to the system, as it doesn't yet know if you actually want to click or do something else, e.g. double tap and move, which means click and drag. So if you actually double tap, it sends both clicks at the end of the second tap as a single event, so AutoHotkey can't interfere. (However, it works if you double tap slowly enough that the first tap is sent as a click by itself, but quickly enough that the second tap/click still counts as double click; but it's tricky to get it right.)
So I modified it as follows:
#If WinActive("ahk_class Chrome_WidgetWin_1")
~LButton::
if (A_TimeSincePriorHotkey < 400) and (A_TimeSincePriorHotkey <> -1)
{
MouseMove, 3, 0, 0, R
MouseClick
MouseClickDrag, Left, 0, 0, -1, 0, 0, R
}
return
#If
So I scrap the first double click since I can't interfere with it, and redo the double click with the mentioned trick. The first mouse move is to prevent those new clicks to be interpreted as triple/quadruple clicks which would select the whole paragraph. It turns out that at least a 3-pixel move is necessary for that. So make sure not to click at the right edge of the word!
Triple click to select paragraph still works fine with this. However, double-click-and-drag to select multiple whole words, or triple-click-and-drag to select multiple whole paragraphs doesn't, since that is that feature that we utilize to select a single word. But if you occasionally use those features as well, it is possible to add an item to AutoHotkey menu to disable this specific workaround whenever needed.
This workaround works in all Chromium browsers, as well as Electron apps that inherit the same text selection from Chromium (I tested on Whatsapp), since they all have the ahk_class Chrome_WidgetWin_1
. If you just want it to work on a browser or a specific app, it is possible to do that by changing the if statement, e.g. #If WinActive("ahk_exe vivaldi.exe")
in my case, as I use Vivaldi.
AutoHotkey is quite flexible, and you could use it for a system-wide solution that works outside browsers and Electron apps. E.g. whenever you double click anywhere (detected with the same method as above), AutoHotkey can check if a trailing space is included in the selection, and send Shift + Left Arrow if it does. I didn't bother, as browsers were where this behavior annoyed me the most.