Bug 100777 - Inconsistent "Smart Cursor" action when navigating or selecting paragraphs
Summary: Inconsistent "Smart Cursor" action when navigating or selecting paragraphs
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:
 
Reported: 2016-07-05 18:22 UTC by Paul
Modified: 2016-09-01 18:50 UTC (History)
5 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 Paul 2016-07-05 18:22:22 UTC
When editing documents with large paragraphs the following inconsistency makes navigation difficult.

If the cursor is in paragraph 2, when I press Ctrl-Up I expect it to go to the top of  the same paragraph, 2. Instead, it jumps to the top of paragraph 1. This is not standard behavior.

However, if I press Ctrl-Shift-Up while in para 2, the cursor Selects to the top of para 2, just as I would expect. The next press of the Up key will jump to the top of Para 1. Perfect.

Keyboard shortcuts are set to standard in this regard. Ctrl-Up and Ctrl-Shift-Up are set to go to the "previous paragraph". But both ought to first stop at the top of the present paragraph, if the cursor isn't already there.
Comment 1 V Stuart Foote 2016-07-06 00:38:53 UTC
That <ctrl>+<up/down> behavior is intentional and has had this behavior since OOo.

--From the help for Shortcut Keys of LibreOffice Writer--

Arrow Up: Move cursor up one line

Shift+Arrow Up: Selecting lines in an upwards direction

Ctrl+Arrow Up: Move cursor to beginning of the *previous* paragraph

Ctrl+Shift+Arrow Up: Select to beginning of paragraph. Next keystroke extends selection to beginning of previous paragraph

Arrow Down: Move cursor down one line

Shift+Arrow Down: Selecting lines in a downward direction

Ctrl+Arrow Down: Move cursor to beginning of *next* paragraph.

Ctrl+Shift+Arrow Down: Select to end of paragraph. Next keystroke extends selection to end of next paragraph

*emphasis mine

See no advantage to changing what has been consistent UI for duration of project.
Comment 2 Paul 2016-07-06 00:54:21 UTC
Ctrl+Arrow Up: Move cursor to beginning of the *previous* paragraph

Ctrl+Shift+Arrow Up: Select to beginning of paragraph. Next keystroke extends selection to beginning of previous paragraph


I'm sorry to see this suggestion blown off. The above behavior of Ctrl+ArrowUp is  internally inconsistent, and IME contrary to accepted and best practice.
Comment 3 V Stuart Foote 2016-07-06 02:59:17 UTC
Not being intentionally dismissive, but as submitted, NOTABUG remains the correct resolution of this report.

Simply put there is no bug, the current cursor behavior and navigation *is* the documented legacy behavior of OpenOffice and LibreOffice--our standard.

(In reply to Paul from comment #0)
> ... This is not standard behavior.

(In reply to Paul from comment #2)
> ... IME contrary to accepted and best practice.

Your opinions, and rather subjective. 

And had you made this an enhancement request for review of and a change in cursor behavior, documenting the source for your perceived "standard" and "accepted and best practice" it would have been reviewed as such--but as is NOTABUG.
Comment 4 Heiko Tietze 2016-07-06 06:59:15 UTC
As the our standard is not the default it could be treated as a bug. The issue results from the fact that users coming from other office suites wonder where the cursor has been gone on ctrl+arrow.
Comment 5 Paul 2016-07-06 13:50:56 UTC
Whether it's a bug or a feature request, I don't know or care much, and I don't think this platform supports formal feature requests in any case. While I appreciate everyone's contributions here, what I do care about is that a good idea is shelved because it doesn't fit the platform's strict technical definition. That is an opportunity missed and will discourage further participation.
Comment 6 Zenaan Harkness 2016-08-28 13:07:27 UTC
I've been bitten ("surprised") by this quite a few times - unfortunately come from very heavy use of WordXP over many years.

This "standard OO/LO behaviour" is:
1) internally inconsistent:
 - Ctrl+Arrow Up: Move cursor to beginning of the *previous* paragraph
 - Ctrl+Shift+Arrow Up: Select to beginning of paragraph. Next keystroke extends selection to beginning of previous paragraph

the different semantics between "movement" and "selection movement" is in principle not good. If someone can find a standard showing this is not standard, that could be an argument to change the default behaviour in LO.

2) very jarring to those who come from, and have used, many different MSWindows AND GNU/Linux programs which ALL demonstrate the alternative (what we call "standard") behaviour!

I have NEVER in my 35 years of computing EVER seen Ctrl+ArrowUP behave as in LibreOffice!

Even if this behaviour is not a dejure standard, it sure is a defacto standard!
Comment 7 Zenaan Harkness 2016-08-28 13:12:50 UTC
OK, "notabug", according to this bug's current wording.

Do we need to file a new feature request bug?

Or do we need to do something else?

I propose something along the lines of the following:

LibreOffice CTRL+ArrowUp behaviour should be customizable, to allow for "traditional" or defacto (i.e. non-LibreOffice) behaviour, namely, to allow for the behaviour of CTRL+ArrowUp to match in movement, the behaviour of the selection shortcut CTRL+SHIFT+ArrowUp.

LibreOffice default CTRL+ArrowUp behaviour is inconsistent with all other programs that anyone knows of, including but not limited to the following:
- Microsoft Office
- Microsoft Word, all versions
- Microsoft Notepad, all versions
- Notepad++ on all platforms
- Eclipse on all platforms and in all configurations
- Geany, Gedit, and numerous other GNU/Linux editors
- numerous other cross-platform text editors
- All known proprietary IDEs
- all other known cross platform text editors and IDEs
Comment 8 Paul 2016-08-28 13:44:11 UTC
Thank you, well said. I would say, though, that we don't need another option to further complicate the program, we just need the behavior corrected.
Comment 9 Cor Nouws 2016-08-28 19:32:14 UTC
the fact that this behavior is here since ~2001 and that I haven't seen complaints, nor bothered myself, at least says something ;)

Note:
There has been a change in this area long time ago - OOo times:
Initially, Ctrl+Up/Down, moved the current paragraph up/down.
That behavior had been exchanged with Ctrl+Alt+Up/Down - which on Ubuntu/Unity is used for something else. (But who cares - Ctrl+Shift+Up/Dwn, Copy, Move, Paste is fast enough for the few occasions - in my situation anyways.)
Comment 10 Heiko Tietze 2016-08-29 07:10:23 UTC
(In reply to Zenaan Harkness from comment #7)
> Do we need to file a new feature request bug?

I vote for changing the long-term LibO behavior in order to be compliant with other tools. Unless someone finds an argument why ctrl+arrow should jump to the paragraph after the current.

So the requested change is to make ctrl+cursor working like shift+crtl+cursor.
Comment 11 Tomaz Vajngerl 2016-08-29 08:45:42 UTC
I agree that we change this behavior.
Comment 12 Cor Nouws 2016-08-29 10:43:27 UTC
(In reply to Heiko Tietze from comment #10)

> I vote for changing the long-term LibO behavior in order to be compliant
> with other tools. Unless someone finds an argument why ctrl+arrow should
> jump to the paragraph after the current.

If other tools have a different behavior, that's a good reason to look at it.

Now when one wants to make a selection, it's logic that that is from the current cursor position.
But when one wants to travel over various paragraphs, it's logic to go to the next or previous.

> So the requested change is to make ctrl+cursor working like
> shift+crtl+cursor.

I can understand the confusion with people that know how it works in other tools. I'm not convinced however, that that behavior is better.
As written, the fact that this behavior is here since ~2001 and that I haven't seen complaints, at least says something.
Comment 13 Heiko Tietze 2016-08-29 11:15:50 UTC
(In reply to Cor Nouws from comment #12)
> But when one wants to travel over various paragraphs, it's logic to go to
> the next or previous.

Not the best argument as both approaches have the same behavior after the first action. I believe the consideration was what happens when the cursor is placed only a few characters away from the paragraph beginning. Word and all other text editors jump one character to the left, LibO the full previous paragraph. Inconsistency is bad.

I started a survey on G+ https://plus.google.com/u/0/107566594492891737454/posts/5hy7FY5Pe83 (and so far surprisingly many people expect the LibO behavior).
Comment 14 Cor Nouws 2016-08-29 12:07:38 UTC
(In reply to Heiko Tietze from comment #13)

> Not the best argument as both approaches have the same behavior after the
> first action. 

It's convincing for me ;)

> I believe the consideration was what happens when the cursor
> is placed only a few characters away from the paragraph beginning. 

yeah.. then it's odd. tweak the algorithm and add an expert config to set the number of characters :D

Word and
> all other text editors jump one character to the left, LibO the full
> previous paragraph. Inconsistency is bad.

I can't understand why a different behavior with different key combination is inconsistency.

> I started a survey on G+
> https://plus.google.com/u/0/107566594492891737454/posts/5hy7FY5Pe83 (and so
> far surprisingly many people expect the LibO behavior).

Thanks - not sure if the sole expectation is the best ground for a discussion on the best behavior, but after all, when I'm honest: a single up/down more or less can't bother me (the ctrl-key is pressed ~continuously anyway  ;) )

(So I'll rest may case. Unless of course others call me to support their view.)

(Sorry Hieko, not intending to nag you, but sometimes these things happen ;) )
Comment 15 Heiko Tietze 2016-09-01 08:26:28 UTC
(In reply to Cor Nouws from comment #14)
> Thanks - not sure if the sole expectation is the best ground for a
> discussion...

Definitely not. But it is an additional information: >80% (with n~100) expect what is suggested here as change.

Another argument is the way how the opposite direction is done: it jumps to the beginning of the next paragraph, and to the end when shift is pressed. If we go ahead with the proposal (what I still vote for) and keep the arrow down behavior, which is as expected, we end up with a minor inconsistency. Guess only the very pedantic users will figure this out.
Comment 16 Heiko Tietze 2016-09-01 08:28:40 UTC
BTW: Neither Calc nor Impress/Draw allows to jumpf through text with ctrl. Thought actually this would be provided by the OS/DE, but apparently it isn't. Or is this just an on/off property?
Comment 17 Paul 2016-09-01 13:29:21 UTC
(In reply to Cor Nouws from comment #14)

> I can't understand why a different behavior with different key combination
> is inconsistency.

Hello,

Here's the way I view this. The current behavior is not analogous to other behavior internal to LO. For instance, if I use the Left key, the cursor goes back one character. If I overlay the Shift key to that action, I Select back one character. If I use Ctrl-Left, the same dynamic holds true with regard to whole words. The Shift key acts as an overlay to an existing action, adding the Selection function.

The same is true of the Up arrow. It will take you up one line. And when the Shift key is added, it will Select up one line.

All these dynamics hold true for the Right and Down keys as well. Adding the Shift key simply adds the Select function to the existing underlying function. 

This holds true when adding the Ctrl key to the Down action- the action is shifted to the paragraph level, but remains consistent. The only thing that changes is the Selection function is added with the Shift key. 

But there is one glaring exception - the Ctrl-Up function is not analogous to the Ctrl-Shift-Up function. Adding the Shift key not only adds the Selection function, it changes the basic underlying action.

But in this case, adding the Shift key brings the Ctrl-Up action back into conformity to all the other functions listed here. It is the underlying action - Ctrl-Up - that for some reason violates the rule of every other related navigation within LO.

I expect the Shift key merely to add the Select function. Here it doesn't, because it is correct, but the underlying action has, IME, been inconsistently designed.
Comment 18 V Stuart Foote 2016-09-01 15:40:05 UTC
OK, its an enhancement... *still* not a bug.

However, discussion/voting on Heiko's survey suggests the action should be changed for the <Ctrl>+<Up arrow> to position to start of current paragraph -- unless already located there. And only subsequent <Ctrl>+<Up arrow> position to prior paragraph.  Rather than current behavior of positioning to start of prior paragraph.

Tomaž do you have time to assign to yourself and take this?

=-ref-=
help entry will need to be tweaked for changed behavior
http://opengrok.libreoffice.org/xref/help/source/text/swriter/04/01020000.xhp#615

https://plus.google.com/u/0/107566594492891737454/posts/5hy7FY5Pe83
Comment 19 Heiko Tietze 2016-09-01 18:50:58 UTC
Any suggestion from the UX team will be accepted by the ESC (put it onto the table today and there was no objection to stay with the current behavior).

Removing ux-advice from CC since its a fully qualified request now :-).