Bug Hunting Session
Bug 89154 - EDITING: Ctrl+Right key - cursor doesn't stop at the end of the line, jumps to next paragraph
Summary: EDITING: Ctrl+Right key - cursor doesn't stop at the end of the line, jumps t...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: ux-advise (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: Other All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard: target:5.1.0
Keywords:
: 101539 (view as bug list)
Depends on:
Blocks:
 
Reported: 2015-02-05 23:24 UTC by Daniel T.
Modified: 2016-09-15 17:37 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments
Selection technique (Linux) (156.65 KB, image/gif)
2015-07-24 19:41 UTC, drm4567
Details
Selection technique (Windows) (154.78 KB, image/gif)
2015-07-24 19:42 UTC, drm4567
Details
test document (10.40 KB, application/vnd.oasis.opendocument.text)
2015-07-29 17:21 UTC, Yousuf Philips (jay) (retired)
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel T. 2015-02-05 23:24:12 UTC
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.
Comment 1 Cor Nouws 2015-02-06 09:50:38 UTC
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
Comment 2 Daniel T. 2015-02-06 10:18:28 UTC
(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.
Comment 3 Cor Nouws 2015-02-07 20:48:22 UTC
(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.
Comment 4 Heiko Tietze 2015-02-08 09:36:25 UTC
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.
Comment 5 Daniel T. 2015-02-08 09:57:54 UTC
(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.
Comment 6 Cor Nouws 2015-02-24 08:09:19 UTC
@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
Comment 7 Heiko Tietze 2015-02-25 08:28:44 UTC
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.)
Comment 8 Cor Nouws 2015-02-25 09:04:08 UTC
> 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.
Comment 9 Heiko Tietze 2015-02-25 18:37:47 UTC
On KDE it works in the same way (katepart with stops, LO without).
Comment 10 Yousuf Philips (jay) (retired) 2015-02-27 11:31:42 UTC
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.
Comment 11 Cor Nouws 2015-02-27 11:43:47 UTC
(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 :) !
Comment 12 Yousuf Philips (jay) (retired) 2015-02-27 12:31:39 UTC
(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
Comment 13 Heiko Tietze 2015-02-27 12:51:00 UTC
@Jay: You tested with Linux? 
We should confirm your results on Windows 7 and 8 since I got different result.
Comment 14 Yousuf Philips (jay) (retired) 2015-02-27 16:47:09 UTC
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.
Comment 15 V Stuart Foote 2015-02-27 18:13:48 UTC
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.
Comment 16 Yousuf Philips (jay) (retired) 2015-02-28 01:27:47 UTC
(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.
Comment 17 Daniel T. 2015-02-28 15:30:04 UTC
(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...
Comment 18 Yousuf Philips (jay) (retired) 2015-02-28 16:52:27 UTC
(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.
Comment 19 Daniel T. 2015-03-01 15:32:48 UTC
(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.
Comment 20 John Smith 2015-07-24 18:20:08 UTC
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?
Comment 21 V Stuart Foote 2015-07-24 19:03:21 UTC
<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.
Comment 22 drm4567 2015-07-24 19:41:27 UTC
Created attachment 117425 [details]
Selection technique (Linux)
Comment 23 drm4567 2015-07-24 19:42:23 UTC
Created attachment 117426 [details]
Selection technique (Windows)
Comment 24 drm4567 2015-07-24 19:45:31 UTC
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.
Comment 25 Yousuf Philips (jay) (retired) 2015-07-27 17:52:14 UTC
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.
Comment 26 Daniel T. 2015-07-27 18:07:12 UTC
Couldn't agree more.
Comment 27 V Stuart Foote 2015-07-27 18:58:43 UTC
(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!
Comment 28 drm4567 2015-07-27 22:18:01 UTC
> 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.
Comment 29 V Stuart Foote 2015-07-27 23:55:38 UTC
(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.
Comment 30 drm4567 2015-07-28 00:23:50 UTC
> 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?
Comment 31 V Stuart Foote 2015-07-28 01:21:18 UTC
(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?
Comment 32 drm4567 2015-07-28 16:23:18 UTC
> (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.
Comment 33 V Stuart Foote 2015-07-28 19:49:11 UTC
@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.
Comment 34 drm4567 2015-07-28 20:01:01 UTC
> 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.
Comment 35 Yousuf Philips (jay) (retired) 2015-07-29 17:21:50 UTC
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.
Comment 36 Yousuf Philips (jay) (retired) 2015-07-29 18:59:57 UTC
(In reply to Yousuf (Jay) Philips from comment #35)
> the cursor wont stop at the end of line/paragraph 1.

Correction: will stop
Comment 37 Tomaz Vajngerl 2015-08-03 03:47:20 UTC
I have a fix for this ready if we agree this is indeed a bug. :)
Comment 38 Tomaz Vajngerl 2015-08-03 04:05:29 UTC
https://gerrit.libreoffice.org/17484

I would like some Writer expert to look at the patch if it doesn't do something "dangerous".
Comment 39 V Stuart Foote 2015-08-03 11:33:33 UTC
@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.
Comment 40 Commit Notification 2015-08-04 06:28:44 UTC
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.
Comment 41 Cor Nouws 2015-08-10 20:52:15 UTC
(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
Comment 42 Cor Nouws 2015-09-14 14:18:11 UTC
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.
Comment 43 V Stuart Foote 2016-08-21 02:35:03 UTC
*** Bug 101539 has been marked as a duplicate of this bug. ***