Bug 129426 - On arrow key go to the beginning/end of a selection instead continuing at the current character
Summary: On arrow key go to the beginning/end of a selection instead continuing at the...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
6.4.0.0.beta1+
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 129573 (view as bug list)
Depends on:
Blocks: Selection
  Show dependency treegraph
 
Reported: 2019-12-16 10:43 UTC by DM
Modified: 2022-06-09 06:16 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description DM 2019-12-16 10:43:36 UTC
Description:
* If you select some words/characters and press an arrow key it takes the last point you had moved to in the selection and moves left/right by 1 (according to arrow key pressed). Technically that takes the current cursor and adds an arrowed movement.
* The other word editors (eg see Notepad2, Word, Notepad) I have operate entirely differently, and in a much more practical way. An arrow left collapses the selection so the cursor is at the start of the selection whilst an arrow right collapses the selection so the cursor is at the end of the selection. A further arrow press will then actually move the cursor.
* My strong recommendation is to follow this second method as it is really far more useful and workable. (It further fits in with how most people would think of a selection as from left to right irrespective of the computer's memory of how it was drawn out.)

Version: 6.4.0.0.beta1 (x64)
Build ID: 4d7e5b0c40ed843384704eca3ce21981d4e98920
CPU threads: 2; OS: Windows 10.0 Build 18362; UI render: default; VCL: win; 
Locale: en-GB (en_GB); UI-Language: en-GB

Steps to Reproduce:
.

Actual Results:
.

Expected Results:
.


Reproducible: Always


User Profile Reset: No



Additional Info:
Comment 1 Dieter 2019-12-16 16:54:36 UTC
I agree
Comment 2 Heiko Tietze 2019-12-17 11:03:20 UTC
Kate behaves as well like this and +1 from my side too.
Comment 3 Heiko Tietze 2020-01-07 09:02:40 UTC
*** Bug 129573 has been marked as a duplicate of this bug. ***
Comment 4 V Stuart Foote 2020-01-07 14:48:55 UTC
No, this is not valid requirement.

<Ctrl>+<Shift> with cursor <Right, or Left> currently modifies selection and repositions text cursor to beginning or end of the run. Resulting selection includes a trailing space so break at word bound.

It also correctly observes RTL/LTR sense of the locale. 

And what is uniquely StarOffice/OpenOffice/LibreOffice text handling, a <Shift> with cursor <Right, or Left> then allows adjustment of selection, one character at a time.

See no functional requirement to change what is the StarOffice/OpenOffice/LibreOffice way--which currently provides consistent cursor selection of words/lines/paragraphs.[1]  As implemented in edit engine(s) the <Ctrl><Shift> cursor combos alone work at word bounds/line bounds for cursor movement within selections.

Implementation remains correct and suited to task, that it does not exactly match other text editors is not a valid design requirement.

IMHO => WF

=-ref-=
[1] https://help.libreoffice.org/6.3/en-US/text/swriter/04/01020000.html?DbPAR=WRITER#bm_id3145763
Comment 5 Heiko Tietze 2020-01-07 15:26:38 UTC
(In reply to V Stuart Foote from comment #4)
> No, this is not valid requirement.

Appreciate your opinion and welcome further discussion with UX. I'm still for changing this.
Comment 6 Heiko Tietze 2021-06-21 07:23:14 UTC
No more input, so let's recap: In a sentence like "He heard quiet steps behind him." select "quiet steps" from left to right. The cursor is at the right position after "s". Arrow right goes to the next character, the one after space, arrow left to before the "s". The proposal is to stay at the same position on right, and to go to position before the selection ("q") on arrow left. If the selection is mode from right to left we just do the same (after q on right, before the space on left) while the proposal is to also jump to the beginning of the selection on arrow left and the end on right.

Neither shift+arrow nor shift+ctrl+arrow should change.