Ctrl+Right and Ctrl+Left jump between words. However, Ctrl+Right wouldn't stop at the end of line after reaching the last word but jumps all the way to the (beginning of) next paragraph. This is counter-productive and annoying. Steps to reproduce: 1. Have a text consisting of at least two paragraphs. 2. Let the 1st paragraph not end with a punctuation mark (representing a work in progress). 3. Place cursor a few words before the end of the paragraph. 4. Click Ctrl+Right a few times until the cursor is before the first letter of the last word. 5. Click Ctrl+Right once again. Current behaviour: -> The cursor jumps to the beginning of the next paragraph. Expected behaviour (and this is also how Microsoft Word behaves): -> The cursor stops at the end of the line, i.e. just after the end of the last word there and whether or not the line is finished with a punctuation mark. This would enable a much more pleasant work as one uses Ctrl+Right a lot to quickly skip between the words in the in-progress paragraph, editing its end a lot. And one doesn't expect to land all of a sudden in the paragraph below.
Hi pterion, Thanks for filing the issue. I confirm the behavior. (Of course there is (Shift-)End as other key available) Do you propose to always stop at the end of the paragraph, or only if the next paragraph is empty? Set component from Writer to UX-advise Cheers Cor
(In reply to Cor Nouws from comment #1) > (Of course there is (Shift-)End as other key available) Shift+End amounts to a different key combination from the one used to skip between the words in a normal editing period. I'd need an adjustment period. > Do you propose to always stop at the end of the paragraph, or only if the > next paragraph is empty? I propose to always stop at the end of the paragraph before jumping to the next one, whether empty or not. This is the behaviour most user be familiar with. Including newcomers from Microsoft Word. I haven't been using Word for years now but all those years I'm irritated at the reported jumps.
(In reply to pterion from comment #2) > Shift+End amounts to a different key combination from the one used to skip > between the words in a normal editing period. I'd need an adjustment period. But it will help you a lot when you´'re half way a line ;) > I propose to always stop at the end of the paragraph before jumping to the > next one, whether empty or not. [...] Fine for me! If no one from UX-advise shows objections, I'll set it to new.
Objection! It's up to the OS how keys are handled. And to my knowledge there is is none with stop at paragraph's end. Ctrl+right/left just looks for white space characters (tab, space, minus, etc.) and not line feed. If you need an option to select a paragraph you may use the triple click. For keyboard access we'd have to define a new key, which makes sense. I'd suggest alt(+shift) + pos1/end as default to jump to the beginning or end of the paragraph. But I'd definitely not tweak the system behavior.
(In reply to Heiko Tietze from comment #4) > Objection! It's up to the OS how keys are handled. And to my knowledge there > is is none with stop at paragraph's end. The idea is not to stop at the paragraph end but at the end of the last word. This is how text editors and text fields (e.g. in the browsers) work across the OS.
@heiko: I think Daniels explanation makes sense. Indeed I do 'suffer' from the behavior too, be am so used to it, that I just swiftly hit another two/three keys to correct the situation. Coincidentally, there is also the related issue, tdf 89602 :) Cheers, Cor
To my knowledge ctrl+cursor jumps to the next whitespace character (dev should confirm this). And what I mean is that the list of whitespace characters that are used for cursor stop should not be individually defined by any program but the OS. If Daniel would be right with stop at the line feed I would agree with his bug report. But when I try with dummy text in LO 4.4 and within this dialog (Firefox v35; both under Windows Seven) I get the same sequence for ctrl+left/right that jumps over the line feed. "waiting for a chance to grab the *fruit *of *his *labor *Or *did *the steps behind him mean that one of many" (Stars denote the cursor stop here) What I expect too is the same behavior back and forth. If you stop at the paragraph end it should stop for both left and right movements, which could be strange though. (BTW: The stars are also treated for cursor stops. So my whitespace argument is very questionable.)
> To my knowledge ctrl+cursor jumps to the next whitespace character (dev > should confirm this). And what I mean is that the list of whitespace > characters that are used for cursor stop should not be individually defined > by any program but the OS. On Ubuntu, LibreOffice behaves different from Gedit, Thunderbird, FireFox, .. The latter all stop (forth and backwards) at the end/beginning of a line/paragraph too. LibreOffice does not.
On KDE it works in the same way (katepart with stops, LO without).
How these apps behave. Google Docs: stops at end of line Calligra Words: stops at end of line WPS Writer: stops at end of line WordPerfect: stops at end of line Abiword: stops at end of line Textbox in Browsers: stops at end of line Basically LO's behaviour has to be tweaked to also stop at paragraph endings, as this is the norm.
(In reply to Jay Philips from comment #10) > Basically LO's behaviour has to be tweaked to also stop at paragraph > endings, as this is the norm. "line ends" Yes - thanks for the overview :) !
(In reply to Cor Nouws from comment #11) > "line ends" correction: line and paragraph ends, as you have regular enter (paragraph end) and shift+enter (line end). :D
@Jay: You tested with Linux? We should confirm your results on Windows 7 and 8 since I got different result.
Yes my statement that all textboxes in browsers were the same was just a guess as i only tested the browser i use (Opera). :D Testing firefox and chromium and they dont stop at the end and internet explorer stops at the end of the line.
Hmmm, Not so sure about all this, since <Ctrl>+<Right arrow> or <Crtl>+<Left arrow> are advancing at word boundaries/white space. Their behavior actually is correct when moving across the Paragraph marker and into the next paragraph. But a look at the Wiki help for LO Writer shortcut keys https://help.libreoffice.org/Writer/Shortcut_Keys_for_Writer suggests better alternatives. The <End> key is listed as "Go to end of line" and positions cursor directly to the end of current line--isn't that the behavior OP is seeking. Accordingly IMHO I see no reason to change this behavior. As an aside... Also, while <Ctrl>+<Down Arrow> is listed as "Move cursor to end of paragraph", that may never have been correct, or seems to have been changed at some point prior to the LO 3.3.0 release. That shortcut will actually move cursor directly the start of the next paragraph. Matching behavior <Ctrl>+<Up Arrow> which is listed as, and performs, a "Move cursor to beginning of the previous paragraph". So guess at some point behavior of the <Ctrl>+<Down arrow> could have been changed to match that. Interesting in that <Ctrl>+<Shift>+<Down Arrow> will select text up to the end of paragraph. And for what it is worth, the current LO shortcut behaviors are exactly the same in Word 2013 on Windows 7.
(In reply to V Stuart Foote from comment #15) > And for what it is worth, the current LO shortcut behaviors are exactly the > same in Word 2013 on Windows 7. I just tried Word 2013 on Windows 7 and ctrl+right goes to the end of the line.
(In reply to V Stuart Foote from comment #15) > <Ctrl>+<Right arrow> or <Crtl>+<Left > arrow> are advancing at word boundaries/white space. Their behavior actually > is correct when moving across the Paragraph marker and into the next > paragraph. This might perhaps make sense conceptually or on paper but in real writing/editing work this is much less convenient. Besides, I just tested the behaviour in Firefox and Chrome browsers' textareas/textboxes on Linux and Windows -> the cursor DOES stop at the end of a line and of a paragraph. This is by far the norm. I don't know how exactly Jay tested it...
(In reply to Daniel Tkatch from comment #17) > Besides, I just tested the behaviour in Firefox and Chrome browsers' > textareas/textboxes on Linux and Windows -> the cursor DOES stop at the end > of a line and of a paragraph. This is by far the norm. I don't know how > exactly Jay tested it... I tested according to the example you gave, without a punctuation at the end of the first paragraph.
(In reply to Jay Philips from comment #18) > I tested according to the example you gave, without a punctuation at the end > of the first paragraph. Hmm... Me too. The cursor stopped in any case possible. I have difficulty finding another application apart from LO that would in the cursor would jump to the next white space in the next paragraph without stopping at the end of the line.
This is a pretty outrageously horrible flaw. A word processor that can't perform simple word selection is unusable for me. This alone is driving me back to MS Word. What is being done about this bug?
<Ctrl>+<Right> advances to next white space. If that happens to be across paragraph that is as designed/implemented and documented--and is correct. <End> and <Home> position cursor to end of line, and start of line respectively. Some concern over <Ctrl>+<Down> not positioning to end of paragraph, instead goes to Start of following, but simple to <Ctrl>+<Left> to move backwards over EOL whitespace. (In reply to John Smith from comment #20) > This is a pretty outrageously horrible flaw. A word processor that can't > perform simple word selection is unusable for me. This alone is driving me > back to MS Word. "word selection" is not even an issue in this bug. > What is being done about this bug? Resolving as Wont Fix.
Created attachment 117425 [details] Selection technique (Linux)
Created attachment 117426 [details] Selection technique (Windows)
The way LO handles Ctrl+Right and Ctrl+Left is IMO a shame. The selection should not be expanded to a whitespace or a paragraph like it was before (see Selection (Linux) attachment). Now this works the way most application work in Windows (see Selection (Windows) attachment). LO even does not care that it is probably a single app that behaves in Linux that way.
Reopening as all word processors work in this fashion and i think LO should do the same. Adding this to the design PAD for discussion.
Couldn't agree more.
(In reply to Yousuf (Jay) Philips from comment #25) > Reopening as all word processors work in this fashion and i think LO should > do the same. > > Adding this to the design PAD for discussion. Comments on the pad, but going to restate that there is no issue with shortcuts as defined. Behavior of in LO Writer **exactly** matches those of MS WordPad, MS Word (2007), and MS Office 365 Word. I.e. <Ctrl>+<Right> passes over the end of paragraph to next word boundary. <End> is the correct shortcut to advance to the end of line position. <Ctrl>+<Shift>+<Right> selects full word (including end space). And <Ctrl>+<Shift>+<Down> selects paragraphs. Nothing to be changed!
> Behavior of in LO Writer **exactly** matches those of > MS WordPad, MS Word (2007), and MS Office 365 Word. Yes, and this is the most annoying feature of MS Office! I use <Ctrl-Shift-Right> to select a line in Word, I get the entire table selected instead! I use Shift-End to select this line, I copy it, paste, and - boom! - I have a new paragraph although I just tried to modify this line. Why should LO team ever mimic MS Office? They will never get even near it this way. MSO have a new format - you have this format broken in LO. In 5 years you have a moderate support of their format - they have new GUI! And so on, and so forth, LO team will just waste their efforts to create the same popular but irritating product instead of inventing or just trying something new.
(In reply to drm4567 from comment #28) > Yes, and this is the most annoying feature of MS Office! I use > <Ctrl-Shift-Right> to select a line in Word, I get the entire table selected > instead! I use Shift-End to select this line, I copy it, paste, and - boom! > - I have a new paragraph although I just tried to modify this line. > And this is a LO issue how? > Why should LO team ever mimic MS Office? They will never get even near it > this way. MSO have a new format - you have this format broken in LO. In 5 > years you have a moderate support of their format - they have new GUI! And > so on, and so forth, LO team will just waste their efforts to create the > same popular but irritating product instead of inventing or just trying > something new. Or, seen another way. It works (and has always worked) correctly. It aint broke...don't "fix" it.
> And this is a LO issue how? Well, since new versions of LO mimic MSO behaviour, it *has* become LO's issue now. I don't remember this whimmy Ctrl-Shift-{Right,Left} behaviour in old OO and LO versions. > Or, seen another way. It works (and has always worked) correctly. It aint > broke...don't "fix" it. OK, why LO team constantly "fixes" old good things then?
(In reply to drm4567 from comment #30) > > And this is a LO issue how? > > Well, since new versions of LO mimic MSO behaviour, it *has* become LO's > issue now. I don't remember this whimmy Ctrl-Shift-{Right,Left} behaviour in > old OO and LO versions. > Seriously? But feel free to download archive builds, please: LO 3.3.0+ http://downloadarchive.documentfoundation.org/libreoffice/old/ AOO 4.0+ http://archive.apache.org/dist/openoffice/ AOO 3.4.0, 3.4.1 http://archive.apache.org/dist/incubator/ooo/files/stable/ OOo < 3.3.0 http://archive.apache.org/dist/incubator/ooo/stable/ Check a few of them, then let us know if you'd care to reevaluate your intransigence?
> (In reply to V Stuart Foote from comment #31) OK, I'm sorry, you're probably right. I haven't used LO for quite a while. Anyway, it would be great for native Linux LO to have the same selection behaviour as all X apps do.
@Jay, (In reply to Yousuf (Jay) Philips from comment #10) > Google Docs: stops at end of line > Calligra Words: stops at end of line > WPS Writer: stops at end of line > WordPerfect: stops at end of line > Abiword: stops at end of line > Textbox in Browsers: stops at end of line > > Basically LO's behaviour has to be tweaked to also stop at paragraph > endings, as this is the norm. Sorry, simply not seeing this on Windows 7sp1 or Windows 8.1. Just checked Google Docs, Abiword, Caligra, browser (FF/Chrome) based text boxes, Office 2013, Office 2010, Office 2007, builds of LO, builds of AOO. And, for <Ctrl>+<Right> movement or <Ctrl>+<Shift>+Right selection **none** of them "stop" at Paragraph endings, they'll roll right through white space (newline or paragraph end) to next line or paragraph. And again <End> moves to or <Shift>+<End> selects to End of current Line.
> Sorry, simply not seeing this on Windows 7sp1 or Windows 8.1. > > Just checked Google Docs, Abiword, Caligra, browser (FF/Chrome) based text > boxes, Office 2013, Office 2010, Office 2007, builds of LO, builds of AOO. Look at my attachments above and you'll understand why. It's system specific. That's why it feels so weird when native Linux LO behaves like a common Windows app.
Created attachment 117519 [details] test document Here is a test document to work with, so we are all on the same page according to the bug description. Steps: 1) Open doc 2) Press Ctrl+Right on line/paragraph 1 3) Notice that it doesnt stop at the end of the line as it doesnt have punctuation 4) Try this on line/paragraph 2. 5) It stops before the period This is the behaviour in 3.3 and master. Try this same thing in Word 2013, WPS Writer, and other word processors and the cursor wont stop at the end of line/paragraph 1.
(In reply to Yousuf (Jay) Philips from comment #35) > the cursor wont stop at the end of line/paragraph 1. Correction: will stop
I have a fix for this ready if we agree this is indeed a bug. :)
https://gerrit.libreoffice.org/17484 I would like some Writer expert to look at the patch if it doesn't do something "dangerous".
@Tomaž I am not an expert, but for cursor movement, defining previous word with an OR test for position as "Start of Word" or "End of Paragraph" seems reasonable. Might have interesting effects navigating in Table cells if that is the same control.
Tomaž Vajngerl committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=8eca4da70506e1e6c2e4b600262cced93aba8c96 tdf#89154 stop at paragraph end when using CTRL+Right (or Left) It will be available in 5.1.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to Tomaz Vajngerl from comment #38) > https://gerrit.libreoffice.org/17484 > > I would like some Writer expert to look at the patch if it doesn't do > something "dangerous". Thanks - will download daily and test it! Cor
tested in daily 2015-09-14 on 32 bits Linux. Works great. I see no interference with selecting paragraphs (Ctrl+Up/Down). Don't see any difference when making a selection in a table... So I think it's fine for 5.0.x too.
*** Bug 101539 has been marked as a duplicate of this bug. ***