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:
I agree
Kate behaves as well like this and +1 from my side too.
*** Bug 129573 has been marked as a duplicate of this bug. ***
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
(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.
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.