In Windows, it seems the default behavior when double-clicking a word is to select the word, and any whitespace following the word (spaces or tabs). You can see this behavior across all programs, so I'm assuming this isn't a per-program setting. This may be common to other operating systems, but I don't know from personal experience.
Is this something that can be configured in the OS anywhere or is it something I just have to live with?
I double click on the word, but hold the second click and drag it slightly. For some reason selecting multiple whole words (double-click and drag) doesn't select the whitespace afterwards, so you can double-click and drag just the one word.
Tested on Windows 10 (build 17758).
As far as I am aware, this is the default behaviour.
What I often do is to double-click the word and then hold shift and press the left arrow key (application allowing). I have found this to be the quickest method rather than attempting to precisely select the word under scrutiny with the mouse which is often a little tricky and fiddly.
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.
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.
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:
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.
Simplest method for me: double click first selects word with following space, then hold shift and single click on same word (or click on any another word to extend selection). This selects word(s) without space.
Easiest way to do this is double click, but do not release the mouse button on the second click. Then drag up (or down) slightly while still holding the mouse button down. You now will only have the word selected without a space on the end.
On my Windows 10 PC I had assigned a macro to my middle mouse button to take off the last character from the selection and then copy it to the clipboard.
The macro from the MS Mouse & Keyboard Center looks like this: copy without trailing space macro
Specifically within Microsoft Word, you can adjust this behaviour:
First, go to File > Options > Advanced > Cut, Copy and Paste.
Then, either:
What is strange about this "feature" is that if you apply an attribute to the selected text (bold, underline, italic, font, etc.) it gets applied to the text only and not to the following space. On the other hand, if you delete the word, the space goes too.
On the third hand, if you manually select the word and the following space (i.e not by double-clicking), and then apply an attribute, it will be applied to the following space as well.
In other words, double-clicking and manually selecting look like the same selection (word + following space), but the behavior is different.
I can understand the logic in this, but it still annoys me. For years I've been unnecessarily removing the following space from double-clicked word selections (shift-left arrow) before applying font attributes. Now I'm trying to train myself to stop doing that, since it makes no difference, but old habits die hard.
