Description: Imagine a text line like: aaa bbb ccc ddd (words separated by several tabs and/or spaces) If you are e.g. at the word “aaa” and use CTRL+SHIFT+right-arrow to select ONLY the word, the selection also takes the spaces/tabs behind the word. Btw, if you are at the right-end of a word like “ddd” and use CTRL+SHIFT+arrow-left, the selection is OK, no tabs/spaces used. Steps to Reproduce: 1. Write a text line with words separated by (several) spaces and tabs 2. Go to begining of a word and use CTRL+SHIFT+right-arrow to select or or many words 3. The selection will also take the spaces/tabs behind the word Actual Results: The selection takes too much, all useless spaces/tabs after the word. Expected Results: Selection stops on end of the word. Reproducible: Always User Profile Reset: No Additional Info: If you are at the right-end of a word like “ddd” and use CTRL+SHIFT+left-arrow, the selection is OK, no tabs/spaces. If this is not a bug, this needs a new option to stop the selection at the end of the word.
Thanks for reporting geoff. I can reproduce this with Windows and Linux. Left arrow works normal, but right arrow behaves different: Windows10 64bit, LO 7.1.8.1 and Version: 7.3.3.2 / LibreOffice Community Build ID: 30(Build:2) CPU threads: 16; OS: Linux 5.13; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Ubuntu package version: 1:7.3.3~rc2-0ubuntu0.20.04.1~lo1 Calc: threaded also in linux64-6.1 binary
Already in version 3.3.0. I guess it would be better to change the behaviour. I tested with some applications and it varies. In Firefox, it only selects the word. In KDE, Dolphin and Kate behave like LibreOffice.
Considering bug 149254 this request is not a bug.
(In reply to Heiko Tietze from comment #3) > Considering bug 149254 this request is not a bug. bug-149254 is about double click (mouse), I am talking about about keyboard. This needs a new program option: the user can decide what to select: stop on the (last) word or also including trailing spaces. Some users want trailing spaces, some don't ... who is right? => add an option Thx.
(In reply to Buovjaga from comment #2) > In Firefox, it only selects the word. Not in Windows 10. (In reply to geoff from comment #0) > Expected Results: > Selection stops on end of the word. And what is selected with the next stroke of Ctrl+Shift+Right_arrow? The spaces/tabs between the actual word and the next? Or only the first shortcut stroke do not select spaces/tabs? I think that there must be consistency between the selection of words and paragraphs. Just tested with Ctrl+Shift+Up/Down_arrow, and this selects to the next leftmost/rightmost position of paragraph (not to the next beginning of paragraph; the behavior has changed from the last time I used it; is not what I expected; but consistency is important).
IMO: WF. The problem is not with copy, but rather with paste, where we could do better, trying to not create double spaces (i.e., dropping leading/trailing spaces in the pasted data where it makes sense). Or what complete scenario (other than pasting with unwanted spaces) gets broken with the current behavior?
> (In reply to geoff from comment #0) > > Expected Results: > > Selection stops on end of the word. > > And what is selected with the next stroke of Ctrl+Shift+Right_arrow? The > spaces/tabs between the actual word and the next? > Or only the first shortcut stroke do not select spaces/tabs? > > I think that there must be consistency between the selection of words and > paragraphs. > Just tested with Ctrl+Shift+Up/Down_arrow, and this selects to the next > leftmost/rightmost position of paragraph (not to the next beginning of > paragraph; the behavior has changed from the last time I used it; is not > what I expected; but consistency is important). The next stroke will do the same as the first/previous stroke: select the next word including whitespace behind it.
(In reply to Mike Kaganski from comment #6) > IMO: WF. The problem is not with copy, but rather with paste, where we could > do better, trying to not create double spaces (i.e., dropping > leading/trailing spaces in the pasted data where it makes sense). > > Or what complete scenario (other than pasting with unwanted spaces) gets > broken with the current behavior? Paste can be anywhere, in any program ... not just LO, it should produce same result anywhere. So, the correct/desired handling must happen before Paste ... either in text selection (which is logical to me: the user can see what is selected) or when using copy (CTRL+C, an option to trim leading/trailing whitespace before copy-to-clipboard).
(In reply to geoff from comment #8) Even then, I'd say WF. The request is in the "infinite configurability" realm, and it's already possible to use macros (together with key assignment) to achieve the wanted behavior using XWordCursor interface [1] and its gotoStartOfWord/gotoEndOfWord. [1] https://api.libreoffice.org/docs/idl/ref/interfacecom_1_1sun_1_1star_1_1text_1_1XWordCursor.html
OTOH, the .uno:WordRightSel that is assigned to Ctrl+Shift+Right is named "Select to End of Word" (see Customize), so there is likely some back-and-forth here with the behavior of that command, with original intent maybe being what OP wanted here. FTR, StarOffice 5.2 from 2000 behaved like this proposal wants; but OOo 3.2.0 already worked as today.
(In reply to LeroyG from comment #5) > I think that there must be consistency between the selection of words and > paragraphs. I believe that *this* consistency is unimportant; jumping through different entities (characters/words/paragraphs/pages) would not be confusing, if they are a bit different (in the end, the entities themselves are different). What is important is the consistency between Crtl+Shift+Right and Ctrl+Right, i.e. selection vs movement in the same direction. IIUC, the current behavior makes it convenient for users to move through the document word-by-word using keyboard, and selection follows this. Indeed, when you want to select several words, you would do it faster if you don't need to press keys again just to skip the space between words.
And what is with CTRL+SHIFT+Left or CTRL+Left? They do not take whitepace (which is fine with me) ... and behave differently than the Right key.
(In reply to geoff from comment #12) Ctrl+Shift+Left (and Ctrl+Left) behave consistently with Ctrl(+Shift)+Right, in that they use the same stop positions: consistently in the beginning of words.
(In reply to Mike Kaganski from comment #13) > (In reply to geoff from comment #12) > > Ctrl+Shift+Left (and Ctrl+Left) behave consistently with Ctrl(+Shift)+Right, > in that they use the same stop positions: consistently in the beginning of > words. Yes, if the word begin is always on the left ... What is actually the LO behaviour for this in regions/settings with right-to-left language? --- I actually see the "begin" at the cursor point ... and expect the same behaviour in both directions. Word-begin is not always precise, "end of text" (and whitespace is not text) is more accurate. If you like hiking: in one direction you go over the river/sea, in other direction you stop at the coast => not the same behaviour. I think, this needs a new program option.
Note that we will not introduce new *options* here that would change behavior, because changing the behavior of the UNO commands based on a user preference would mean that any macro using those UNO commands would break. If UX decides this is worth implementing, the only way would be to introduce new UNO commands, that would behave the wanted way, thus allowing users to customize their keyboard bindings with the new UNO commands. By the way, fixing the description of the .uno:WordRightSel / .uno:WordLeftSel would be a good thing anyway.
I am using MS-Office since 20+ years and wanted to give LibreOffice a chance. After fey days of usage, I could arrange with many things (e.g. LO start is much slower), could make/configure some things better than in MSO, but I found 2 things (which I reported here) VERY annoying. They cost me a lot of additional clicks and at the end, make me angry and reduce my productivity: because they make no sense but I need them every day, many times. Here is my final test about CTRL(+SHIFT)+right-arrow selection with MSO: 1) MSO 1997 2) MSO 2007 3) Office 365 (version 2205) => NONE of them will take whitespace into selection.
(In reply to geoff from comment #16) > 3) Office 365 (version 2205) > => NONE of them will take whitespace into selection. That's weird and the opposite to my findings. UX approved bug 149254 requesting to include trailing spaces (we don't do so right now).
(In reply to Heiko Tietze from comment #17) > > 3) Office 365 (version 2205) > > => NONE of them will take whitespace into selection. > > That's weird and the opposite to my findings. UX approved bug 149254 > requesting to include trailing spaces (we don't do so right now). I can send screenshots as proof anytime. (englisch Windows, with locale: DE/Germany)
Created attachment 180716 [details] Screencast That's what I get.
(In reply to geoff from comment #18) > (In reply to Heiko Tietze from comment #17) > > > 3) Office 365 (version 2205) > > > => NONE of them will take whitespace into selection. > > > > That's weird and the opposite to my findings. UX approved bug 149254 > > requesting to include trailing spaces (we don't do so right now). > > I can send screenshots as proof anytime. Screenshots in this case would not prove anything while Heiko's screen recording shows whitespace getting selected.
> Screenshots in this case would not prove anything while Heiko's screen > recording shows whitespace getting selected. This is a joke, right? Because one users screenshot is "better" than others? See my first report ... I sent a test like: aaa bbb ccc ddd (words separated by several tabs and/or spaces) I my test, I used 3 tabs between the words. Yes, I tested this on 3 described MSO versions (using default options) and none of them will select the tabs/whitespace. What do you want: 3 videos from me, as another proof?
(In reply to geoff from comment #21) > > Screenshots in this case would not prove anything while Heiko's screen > > recording shows whitespace getting selected. > > This is a joke, right? > Because one users screenshot is "better" than others? You yourself brought up "proof". I only mean to say that you should take a video recording of your screen rather than screenshots.
> You yourself brought up "proof". I only mean to say that you should take a > video recording of your screen rather than screenshots. Heiko used a normal text/document with spaces between the words, but NO tabulators. Just put some TABS between the words and see the difference.
Tabs and spaces are usually combined into white-space, that's true. But in this particular case we better distinguish between the two as you separate words with spaces but rather position text such as numbers with tabs - different workflows. And while we should include the trailing _spaces_ it might be a good idea to not include _tabs_.