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.
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.
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.
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.
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.
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.
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!
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
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.
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.)
(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.
I agree that we change this behavior.
(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.
(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).
(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 ;) )
(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.
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?
(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.
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
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 :-).
*** Bug 142212 has been marked as a duplicate of this bug. ***
How to solve the problem: 1. In Writer, open Tools->Customize 2. Go to Keyboard tab 3. Make sure that (*) Writer is selected at top right corner of the tab 4. Scroll to Ctrl+Up entry in Shortcut Keys list and select it 5. Select "Navigate" in Category list, and type "parag" in search box 6. Select "To Paragraph Begin" in the Function list, and press Modify button. Repeat the same for Ctrl+Down. This should be enough pointer for easy hack.
Mike, thank you for that. It works, with the exception that for my expected behavior Ctrl-Down should remain at "To Next Paragraph" in order to send the cursor to the start of the next para no matter where the cursor is in the current para. The asymmetry between the two commands is regrettable, but that's what it takes to achieve the action I'm looking for, which I believe provides the most natural work flow, and which I believe should be the default configuration. Thanks once again.
(In reply to Paul from comment #22) > The asymmetry between the two commands is regrettable, but ... > I believe provides the most natural work flow, and which I believe > should be the default configuration. The default configuration must be such that the pairs of movement combinations with and without Shift must move cursor to the *same* new position, and the only difference must be the selection created with Shift. This applies to the pairs: Up and Shift+Up Down and Shift+Down Left and Shift+Left Right and Shift+Right PgUp and Shift+PgUp PgDn and Shift+PgDn Home and Shift+Home End and Shift+End as well as combinations including Ctrl: Ctrl+Up and Shift+Ctrl+Up Ctrl+Down and Shift+Ctrl+Down Ctrl+Left and Shift+Ctrl+Left Ctrl+Right and Shift+Ctrl+Right Ctrl+Home and Shift+Ctrl+Home Ctrl+End and Shift+Ctrl+End This creates consistency in movement expectations. A different configuration inevitably creates a cognitive dissonance in users, and bugs like this one. A specific use case can use customized shortcuts.
(In reply to Mike Kaganski from comment #23) But OTOH MS Word behaves exactly according to comment 22. I suppose it's again up to UX team to decide.
Yes, Comment #22 is the way a billion people are used to and expect LO to operate, and while that's not necessarily a sufficient argument, in this case I think MS made a wise decision. It is intuitively correct from the user point of view, if not from the coder point of view, and it is a function that gets used fairly often.
(In reply to Paul from comment #25) OT: I agree with "a billion people are used to and expect LO to operate". But I would avoid references to intuition, because it's a chicken-and-egg problem, our intuition being created from our experience. It's quite possible that it's only "intuitive" *because* MS has made that decision, not the other way round. I'll just wait the decision from UX.
I've assigned this to myself as my first contribution to LibreOffice following the easy hack introductory pathway. Although it's not my first contribution to OpenOffice, or StarOffice as it was at the time, I consider myself a beginner/novice. Patches to replace GotToPrevPara with GoToStartOfPara in the relevant .xcu file has been tested on a local build and both it and the update to the relevant documentation .xhp file are ready to go to review. AFAICT, two separate patches will be required, one each for core and documentation/help which, AFAICT, are two separate teams and commits, presumably with the same gerrit Change-ID so that they can be synchronised. That may be something I need to ask via chat.
(In reply to Ross Johnson from comment #27) > AFAICT, two separate patches will be required, one each for core and > documentation/help which, AFAICT, are two separate teams and commits, > presumably with the same gerrit Change-ID so that they can be synchronised. > That may be something I need to ask via chat. You can submit two patches and use tdf#100777 as reference in the summary. Or just do one patch, if you like. We can manage the two different aspects on Gerrit.
Patches have been submitted for review (both core and documentation), unless I've misunderstood the process. The commit messages for both references this issue 100777. Note: Only Ctrl-UP Arrow has changed to GoToSTartOfPara. The ctrl-DN Arrow function has not changed from what it is currently. I believe that was the general concensus. I assume the review process will indicate if that is incorrect.
Patches: https://gerrit.libreoffice.org/c/core/+/122032 https://gerrit.libreoffice.org/c/help/+/122052
rocso committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/74916fc339dcd9fa343e4bd33977733092ee6ca4 tdf#100777 - Bind Ctrl+Up to uno:GoToStartOfPara (instead of prev paragraph) It will be available in 7.3.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Ross Johnson committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/help/commit/103d2d6a3525d7b4972300702bffa92aa71011c3 tdf#100777 - update related documentation for ctrl-UP Arrow