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.
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
Can you please check? Might be info in Documentation is wrong?
"should" is not a good reason, please contribute information concerning your source!
For submitting bug reports you should try
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!
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:
- Ms Word
- Sublime Text
- MySql Workbench
- Zend Studio
- Tom boy notes.
I really think it is the de fadto way of doing ctrl+arrow.
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?
Contribute complete information due to <http://wiki.documentfoundation.org/BugReport>!
- 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
Created attachment 50450 [details]
Created attachment 50451 [details]
Created attachment 50452 [details]
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.
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.
<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.
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
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.
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.
Created attachment 76154 [details]
Screen recording of ctrl-right writer vs MSWord behaviour
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.
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.
I can't reproduce with Version: 18.104.22.168.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.