Bug 149308 - Ctrl+shift+right-arrow should not select the tabulator after word
Summary: Ctrl+shift+right-arrow should not select the tabulator after word
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Selection
  Show dependency treegraph
 
Reported: 2022-05-26 09:11 UTC by geoff
Modified: 2022-06-13 10:44 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Screencast (203.01 KB, image/gif)
2022-06-13 08:29 UTC, Heiko Tietze
Details

Note You need to log in before you can comment on or make changes to this bug.
Description geoff 2022-05-26 09:11:33 UTC
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.
Comment 1 Scott Clewell 2022-06-02 01:06:09 UTC
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
Comment 2 Buovjaga 2022-06-06 17:19:32 UTC
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.
Comment 3 Heiko Tietze 2022-06-09 06:17:46 UTC
Considering bug 149254 this request is not a bug.
Comment 4 geoff 2022-06-09 07:33:42 UTC
(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.
Comment 5 LeroyG 2022-06-09 19:40:57 UTC
(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).
Comment 6 Mike Kaganski 2022-06-10 07:54:14 UTC
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?
Comment 7 geoff 2022-06-10 08:04:56 UTC
> (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.
Comment 8 geoff 2022-06-10 08:12:29 UTC
(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).
Comment 9 Mike Kaganski 2022-06-10 08:42:35 UTC
(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
Comment 10 Mike Kaganski 2022-06-10 08:52:07 UTC
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.
Comment 11 Mike Kaganski 2022-06-10 09:17:36 UTC
(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.
Comment 12 geoff 2022-06-10 09:27:31 UTC
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.
Comment 13 Mike Kaganski 2022-06-10 09:38:26 UTC
(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.
Comment 14 geoff 2022-06-10 10:55:47 UTC
(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.
Comment 15 Mike Kaganski 2022-06-10 11:01:33 UTC
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.
Comment 16 geoff 2022-06-13 07:41:01 UTC
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.
Comment 17 Heiko Tietze 2022-06-13 07:47:50 UTC
(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).
Comment 18 geoff 2022-06-13 07:54:08 UTC
(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)
Comment 19 Heiko Tietze 2022-06-13 08:29:17 UTC
Created attachment 180716 [details]
Screencast

That's what I get.
Comment 20 Buovjaga 2022-06-13 09:13:37 UTC
(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.
Comment 21 geoff 2022-06-13 09:26:37 UTC
> 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?
Comment 22 Buovjaga 2022-06-13 09:46:34 UTC
(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.
Comment 23 geoff 2022-06-13 10:10:38 UTC
> 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.
Comment 24 Heiko Tietze 2022-06-13 10:44:31 UTC
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_.