When extending a selection with keyboard, e.g. shift-ctrl-right, the selection includes the space after the end of the word. This means that any operation on the selection, e.g. italicizing, will also include the extra space. This is not only bad typography (even though it doesn't make any difference in practice), but it is also bad coding practice, if only because it creates problems when converting to other formats where spaces matter. In any case, the space shouldn't be italicized. Other editors (e.g. Obsidian) remedy this by placing the end tag before the space even if the space is included in the selection.
I confirm the described behaviour. Following/Preceding space is not included in selection with double click or chift-ctrl-left. So I would support a change here. I'm sure there are some other reports related to that problem, but I couldn't find them. cc: Design-Team for further input and decision.
See bug 149254 asking for this when using the mouse but bug 149308 to exclude tabs. And maybe many other too. In fact, starting a selection at the beginning of a word you likely want to remove the trailing space to avoid duplication/missing white separation on cut/paste. And for convenience we continue direct formatting, meaning the white space needs to be included; admittedly it's not needed for a selection within existing text. If we introduce some smart algorithm to conditionally add/suppress the trailing white space it does not justify the effort and likely introduces unwanted corner cases. I recommend to not change the behavior.
But why should we have different behaviours when selecting with keyboard arrows and with double click? Why is selecting with right arrow different from selecting with left arrow? And if you just want to select the word and replace or edit IT, current behaviour is inconvenient.
You progress to the beginning of the next word with or without selection. Click selects word > sentence > paragraph, which is just a different workflow. Some related tickets: bug 82735 - Select whole word by mouse omits the following space bug 91860 - Ctrl-Shift-Right selection behavior (including space following last word) does not follow OS behavior bug 129426 - On arrow key go to the beginning/end of a selection instead continuing at the current character bug 129573 - Selecting or highlighting a word or group of words, arrow key to determine where cursor is to rest, at the start or end bug 139030 - Spaces appear at thin air when drag & dropping text (or the visible selecting being wrong) bug 140576 - Triple-clicking to select a sentence in a paragraph and then dragging that sentence to a new location cause the space between sentences to be lost bug 141738 - It's not visible, that blank space before the word is also selected, if you double-click a word bug 154749 White space selection after selecting text
The UNO command WordRightSel activated by Ctrl+Shift+Right is labeled 'Select to End of Word'. What actually happens is selection to the start of the next word. I would expect selection to the end of the current word when the cursor is not already at the end of the word or to the end of the next word when the cursor is at the end of a word. Code pointers: WordRightSel UNO is handled here: sw/source/uibase/shells/txtcrsr.cxx SwTextShell::ExecMoveLingu case FN_NEXT_WORD_SEL: One possible approach is to make a function SwWrtShell::SelectToEndOfNextWord() to replace the use of SwWrtShell::NxtWrd( true ) here.
(In reply to Eyolf Østrem from comment #0) > ... This means that any > operation on the selection, e.g. italicizing, will also include the extra > space ... To apply bold or italics to a word, just putting the cursor in the word is sufficient. Also therefore, (In reply to Heiko Tietze from comment #2) > I recommend to not change the behavior. .. I support that view. Changing the behavior will be a massive PITA for the keyboard workers.
The topic was on the agenda of the design meeting but didn't receive further comments. Some of us suggest to not change the behavior but others vote for consistency. So I'll keep the ticket open to gather further input. Meanwhile you may follow the suggestion in comment 6 and to not select in order to apply a formatting to a word. Boundaries are detected automatically.
(In reply to Cor Nouws from comment #6) > (In reply to Eyolf Østrem from comment #0) > To apply bold or italics to a word, just putting the cursor in the word is > sufficient. For single words, yes, but if the selection is extended to include more words, the issue still applies. Besides, I can't see how you mean this would affect "keyboard workers" – being one myself, this is exactly why I reported the issue. (Unless you mean devs who work on keyboard input.)