Download it now!
Bug 40263 - EDITING: ctrl+shift+rightarrow at end of paragraph additionally highlights contents of next line
Summary: EDITING: ctrl+shift+rightarrow at end of paragraph additionally highlights co...
Status: RESOLVED WORKSFORME
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: Selection
  Show dependency treegraph
 
Reported: 2011-08-21 00:51 UTC by Kervin Ramen
Modified: 2017-12-06 23:32 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Before ctrl+shift+right (70.78 KB, image/png)
2011-08-22 06:09 UTC, Kervin Ramen
Details
Actual results (70.66 KB, image/png)
2011-08-22 06:10 UTC, Kervin Ramen
Details
Expected results (70.28 KB, image/png)
2011-08-22 06:10 UTC, Kervin Ramen
Details
Screen recording of ctrl-right writer vs MSWord behaviour (2.42 MB, video/x-ms-wmv)
2013-03-08 11:36 UTC, Jonathan Monti
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Kervin Ramen 2011-08-21 00:51:46 UTC
When the cursor is before last word of the line, doing a ctrl+right, the cursor moves to the next line. The cursor should move the the end of line.

This is a highly annoying issue.
Comment 1 Rainer Bielefeld Retired 2011-08-22 01:19:05 UTC
I read for "Ctrl+Arrow Right" in 
- Writer Guide - Word Processing with LibreOffice 3.3: 
  "Ctrl+Arrow Right: Goes to end of word."

- Writer  Help from Help package: 
  Ctrl+Arrow Right: Go to start of next word

My experience with "LibreOffice 3.4.3 RC1  – WIN7  Home Premium  (64bit) English UI [OOO340m1 (Build:301)]": Ctrl+Arrow Right moves caret to start of next word. That is in accordance with Help.

I checked behavior in Acrobat REader 10: same behavior as in LibreOffice 3.4.3 RC1

It seem that this report is INVALID, behavior is as written in HELP

David:
Can you please check? Might be info in Documentation is wrong?

@Kervin Ramen
"should" is not a good reason, please contribute information concerning your source!

For submitting bug reports you should try 
<http://wiki.documentfoundation.org/BugReport_Details>

Please file Bug reports with status UNCONFIRMED if your are not absolutely sure that you contributed all required background information and that the problem will be reproducible with information you can provide! 
Thank you!
Comment 2 Kervin Ramen 2011-08-22 04:38:40 UTC
The problem lies with when there is no full stop at the end of the line where it moves to the next line. 

I think it would be good for usability to stop at the end of the line. I use cursor keys a lot with ctrl+arrow or ctrl+shit+arrow and I moreover use a lot of different editors.

So to compare, a list of editors/ide/programs that does it as I say:
- Eclipse 
- Chrome
- Ms Word
- Sublime Text 
- Gedit
- MySql Workbench
- Zend Studio
- Firefox
- Leafpad
- Notepad
- Notepad++
- Tom boy notes.

I really think it is the de fadto way of doing ctrl+arrow.
Comment 3 Rainer Bielefeld Retired 2011-08-22 05:55:42 UTC
Currently it's the intended behavior, no bug.

For Clarification: i doubt that <ctrl+arrow> ever moves to a new text line as you wrote. <ctrl+rightarrow> moves the caret word by word to the right, in all of my tests in front of the first letter of the next word (punctuation is to be checked separately), and the line jump might be a consequence ...

I can't reproduce the behavior you expect for Firefox (text fields), Seamonkey (Text fields), WordPad, MS Editor, MS WORD 2010, AR, Skype (text fields).

The only application I see working as you might expect is EditPad Lite, where the end of the line is a blank and the caret first moves to the end of the blank and with next <ctrl+rightarrow> in front of the first word of the next line. 

So your assumption your expected behavior is de fadto standard  seems a little hazardous.
Can it be that there are some system settings that some of your softwares will respect, but LibO does not?

Please:
Contribute complete information due to <http://wiki.documentfoundation.org/BugReport>!
Here:
- Write a meaningful Summary
- Attach a sample document 
- Attach screenshots with comments (you can add information using LibO DRAW
  and then attach your screenshot with comments as PDF) if necessary, because
  you can not know what others will see with your sample
- Contribute a step by step instruction containing every key press and every 
  mouse click how to reproduce your problem (and if possible how to created a 
  sample document from the scratch)
- add information 
  -- what exactly is unexpected
  -- and why do you believe it's unexpected (cite Help or Documentation!)
  -- concerning your PC 
  -- concerning your OS
  -- concerning your LibO version and localization (UI language)
  –- Libo settings that might be related to your problems 
  -- how you launch LibO and how you opened the sample document
  –- If you can contribute an OOo Issue that might be useful
  -- everything else crossing your mind after you read a.m. URL
Comment 4 Kervin Ramen 2011-08-22 06:09:40 UTC
Created attachment 50450 [details]
Before ctrl+shift+right
Comment 5 Kervin Ramen 2011-08-22 06:10:24 UTC
Created attachment 50451 [details]
Actual results
Comment 6 Kervin Ramen 2011-08-22 06:10:45 UTC
Created attachment 50452 [details]
Expected results
Comment 7 Kervin Ramen 2011-08-22 06:36:21 UTC
I am using Ubuntu 11.04 and I tried it on windows and the same issue exists. I do not believe it is a settings problem.

The reason why I think is is a bug is that most other editors act that way. If I described the problem correctly and you understood it, it makes sense as well on a usability point of view.
Comment 8 Rainer Bielefeld Retired 2011-08-22 10:54:58 UTC
Confirmed accidently, but now again.

Ah, we are talking about selections and <Ctrl+Shift+arrowright>, that's something completely different the Subject and from my expectation.

My attempt to reproduce ( with "LibreOffice 3.4.3 RC1  – WIN7  Home Premium  (64bit) English UI [OOO340m1 (Build:301)]") you find in attached testkit "mytest2.odt" with steps how to reproduce.

When I tried "mytest2.doc" with MS WORD VIEWER, the unexpected additional highlighting did not happen.

My result:
<ctrl+shift+rightarrow> at paragraph end and under particular circumstances additionally highlights contents next line

I see the same behavior in OOo 3.1.1, so current behavior seems to be inherited from OOo.

@Cédric:
Please feel free to reassign (or reset Assignee to default) if it’s not your area or if provided information is not sufficient. Please set Status to ASSIGNED if you accept this enhancement request
Comment 9 David Nelson 2011-08-22 23:52:28 UTC
I checked in the documentation covering Writer (Getting Started guide and Writer guide) and in the online help, and the coverage of the <Ctr>+<RightArrow> key combination. They both talk about the general action but do not go into details about the behavior near the end of a line.

The online help ("shortcut keys; in text documents") says "Go to start of next word". This accurately describes the current general behavior, although additional coverage of behavior at the end of a line might be helpful for people working on macros, for example. 

The documentation for Writer (Writer guide, Keyboard Shortcuts chapter) says "Goes to end of word". This is inaccurate and should be rectified.

I'll forward this bug report to the documentation team list for action.
Comment 10 Björn Michaelsen 2011-12-23 13:27:09 UTC
Since all new unconfirmed bugs start in state UNCONFIRMED now and old unconfirmed bugs were moved to NEEDINFO with a explanatory comment, all bugs promoted above those bug states to NEW and later are automatically confirmed making the CONFIRMED whiteboard status redundant. Thus it will be removed.
Comment 11 Jonathan Monti 2013-03-08 11:36:41 UTC
Created attachment 76154 [details]
Screen recording of ctrl-right writer vs MSWord behaviour
Comment 12 Jonathan Monti 2013-03-08 11:37:19 UTC
I totally agree with Kervin about the annoying ctrl+right issue. When you browse a  text in MS Word, for instance, using the combination of keys ctrl+arrow right, the cursor jumps at the end of each word of the text; when the cursor arrives at the end of a paragraph, it does not stop there, but goes down until it finds the next word. I tried to play a screen record in order to show what happens in MS Word and in Writer. The  program behaviour is probably coherent with what it is expected to do; in fact, the request may be to modify the program in the way illustrated above.
Thanks,
Jonathan
Comment 13 littlesincanada 2014-10-07 23:48:34 UTC
I haven't got anything to compare this with at the moment, but this is something that has become somewhat of an issue for me. The behaviour has changed fairly recently and muscle memory keeps leading me to assume that right-arrow clicking will at some point put me at the end of the paragraph with the result that I keep overshooting.

I agree that this would seem to be a regression. I don't know at what point this behaviour changed.
Comment 14 Thomas Lendo 2017-12-06 23:32:06 UTC
I can't reproduce with Version: 6.1.0.0.alpha0+
Build ID: aa0b08980aba7bc82ab75151129b0c643cde7dfa
CPU threads: 4; OS: Linux 4.10; UI render: default; VCL: gtk3; 
Locale: de-DE (de_DE.UTF-8); Calc: group threaded

Maybe I did something wrong or didn't find the special circumstances when this will happen.

I'll close this issue as RESOLVED WORKSFORME.

Please feel free to reopen as UNCONFIRMED if you encounter this problem in a current LibreOffice version. Thank you.