Download it now!
Bug 91860 - Ctrl-Shift-Right selection behavior (including space following last word) does not follow OS behavior
Summary: Ctrl-Shift-Right selection behavior (including space following last word) doe...
Status: RESOLVED WONTFIX
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-06-04 15:04 UTC by drm4567
Modified: 2020-09-01 09:28 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description drm4567 2015-06-04 15:04:05 UTC
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.
Comment 1 Cor Nouws 2015-06-04 15:41:54 UTC
(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
Comment 2 drm4567 2015-06-04 15:51:09 UTC
(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.
Comment 3 Cor Nouws 2015-06-04 15:57:24 UTC
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
Comment 4 drm4567 2015-06-04 18:25:10 UTC
(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).
Comment 5 Robinson Tryon (qubit) 2016-08-04 23:39:14 UTC
(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
Comment 6 drm4567 2016-08-05 15:56:34 UTC
> 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.
Comment 7 Cor Nouws 2016-08-06 07:55:43 UTC
ah thanks - let's tweak the issue this way. OK?
Comment 8 drm4567 2016-08-06 09:09:10 UTC
(In reply to Cor Nouws from comment #7)
> ah thanks - let's tweak the issue this way. OK?

OK. Thanks!
Comment 9 Yousuf Philips (jay) (retired) 2016-08-07 05:51:29 UTC
(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.
Comment 10 Xisco Faulí 2020-03-09 13:28:55 UTC
Please add keyword 'needsUXEval' and CC 'libreoffice-ux-advise@lists.freedesktop.org' if input from UX is needed.
Comment 11 Thiago Sueto 2020-08-31 15:35:43 UTC
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.
Comment 12 Heiko Tietze 2020-09-01 09:28:51 UTC
(In reply to Thiago Sueto from comment #11)
> Please, do not remove this behavior...

Agreed. Let's resolve WF.