How to reproduce: input some text, use Ctrl-Shift-Right to select words. What is expected (like in older versions): selection does not cover a space following the last word in the selection. If there is a new paragraph following the last word in the selection, then the cursor stays at the end of the last word in the selection. The same takes place in a table. What happens now: selection extends up to the beginning of the new word including the space. If there is a new paragraph following the last word in the selection, then the cursor jumps to the new paragraph. If something is being selected in a table, then the entire table is selected upon reaching the final symbol of it. This is a new behavior that mimics Microsoft Office and is very annoying and degrades usability. Please, remove it or make it optional.
(In reply to drm4567 from comment #0) > This is a new behavior that mimics Microsoft Office and is very annoying and > degrades usability. Please, remove it or make it optional. At your service ;) See Tools>Options>Calc > General .. Use legacy cursor movement when etc. (at bottom) regards, Cor
(In reply to Cor Nouws from comment #1) > (In reply to drm4567 from comment #0) > > This is a new behavior that mimics Microsoft Office and is very annoying and > > degrades usability. Please, remove it or make it optional. > > At your service ;) > See Tools>Options>Calc > General .. Use legacy cursor movement when etc. (at > bottom) > > regards, > Cor 1) Look at the component section. It's Writer, not Calc! 2) I do not have Calc after Tools>Options> in my version.
Apologies! Way too fast :\ One of your complaints is handled in here https://bugs.documentfoundation.org/show_bug.cgi?id=89154 What older versions do you refer to? In LibreOffice 3.3.0 the selection _does_ include the space. Cheers, Cor
(In reply to Cor Nouws from comment #3) > One of your complaints is handled in here > https://bugs.documentfoundation.org/show_bug.cgi?id=89154 So, this bug thread is still in progress? > What older versions do you refer to? > In LibreOffice 3.3.0 the selection _does_ include the space. Strange. I haven't used LO for a year (not sure what the previous version was), but before that I was quite an active user, but never encountered such behavior (however, I do not remember when I learnt this key combination).
(In reply to drm4567 from comment #4) > (In reply to Cor Nouws from comment #3) > > What older versions do you refer to? > > In LibreOffice 3.3.0 the selection _does_ include the space. > > Strange. I haven't used LO for a year (not sure what the previous version > was), but before that I was quite an active user, but never encountered such > behavior (however, I do not remember when I learnt this key combination). Hi all, What's the current status of this bug? Is there still a concern here? Drm4567: Were you able to find a previous version of LibreOffice that worked as you described? If there has been a regression (i.e. a change in UI behavior), it's important for us to identify it and make sure that it was intentional. Status -> NEEDINFO
> Were you able to find a previous version of LibreOffice that worked > as you described? No, it seems that this behavior is not-a-bug. However, I strongly believe Unix version of LO should behave like all other native programs: do not cover a space following the last word in the selection. LO acts now like a common Windows program, but this behavior is weird in Unix.
ah thanks - let's tweak the issue this way. OK?
(In reply to Cor Nouws from comment #7) > ah thanks - let's tweak the issue this way. OK? OK. Thanks!
(In reply to drm4567 from comment #6) > No, it seems that this behavior is not-a-bug. However, I strongly believe > Unix version of LO should behave like all other native programs: do not > cover a space following the last word in the selection. LO acts now like a > common Windows program, but this behavior is weird in Unix. I would disagree with such behaviour been dependent on the OS, as a LO user would have different behaviour when working on LO going between different OSes. All other unix native apps dont share this behvaiour as gnome text editors are different than kde text editors and the decision in bug 89154 was to use the same behaviour found in all windows, linux and online word processors.
Please add keyword 'needsUXEval' and CC 'libreoffice-ux-advise@lists.freedesktop.org' if input from UX is needed.
Please, do not remove this behavior, make it togglable at most. The original comment is suggesting that this degrades usability for what I assume is changing a single word, but removing it would degrade usability for changing/deleting a word in a proper editing workflow. Removing it would add an additional key stroke after the selection in proofreading workflows, with or without Track Changes. If I'm navigating text in a document with Ctrl and get to the beginning of a word, I may select that word with Ctrl+Shift+Right and immediately change it. That is true with or without space. If the selection ended immediately after the word and, say, I remove it, there would be an unnecessary lingering space that I'd have to remove as well. So an additional Shift+Right or Delete press to remove it. Or an additional Right before I removed it. If I however just want to change the word, I should have no more need to edit the word, but the subsequent movement would require Ctrl+Right two times to move to the word after the next. Moreover, text selection itself would be degraded. Say I just deleted a word and the cursor is at the end of the deleted word, before the space; if I want to select the text afterwards to e.g. add a comment with Ctrl+Alt+C (or really any other sort of visual manipulation like highlight or strikethrough, or maybe even pasting text), I will need to jump to after that space before starting the selection. Again, an additional stroke. Unlike the mouse which has free movement after selecting and changing text, the keyboard requires delicate handling of the UX for a proper keyboard-driven workflow, it's very easy to break it. Please take this into account, especially for something that is especially geared towards editing text like Writer.
(In reply to Thiago Sueto from comment #11) > Please, do not remove this behavior... Agreed. Let's resolve WF.