Summary: When moving by word right on OS X (e.g. using Option-right arrow), the text cursor ends right before the first character of the next word instead of right after the last character of the current word. This is inconsistent with other apps on OS X and probably causes VoiceOver to also read in a way inconsistent with other apps on OS X when moving word right. Steps to reproduce: 1. Have this text in Writer: "The quick brown fox jumps over the lazy dog" 2. Put cursor right before "q" in the word "quick" 3. (optional) Turn on VoiceOver (e.g. using Cmd+F5) 4. Press Option-right arrow to move word right Expected results: The cursor ends right after "k" in word "quick" and before the space. If optional step 3. was taken, then VoiceOver will read word "quick" Actual results: The cursor ends right before "b" in word "brown" and after the space. If optional step 3. was taken, then VoiceOver will read word "brown" Regression: Tested on OS X 10.8.4 with LO 4.2 master (commit 39a78087890fb9255a5e47220bac6cfb956fcfe0). Notes: LO behavior is inconsistent with how other apps behave - for example of the apps: * TextEdit * Pages * Mail * Safari * TextMate * pretty much any app on OS X I also think this is the cause of why VoiceOver reads inconsistently with these other apps when moving by word right. What is more "amusing" is that the documentation for -[NSResponder moveWordRight:] basically says LO way is right even though no OS X app behaves that way and instead behaves according to "Expected results" above :-)
The move-by-word command is moving it to the beginning of words. It has always been moving it to the beginning of words.
You make it sound like a natural law even though it is a matter of definition and it seems the definition on OS X is not how LO behaves. I also don't think you should close my (or anyone's) bug without discussing my (their) concerns mentioned in the bug report - or you think the reference OS X apps like TextEdit, Pages, Mail, TextMate I mentioned are buggy in this regard?
Just to make it clear - I am discussing behavior of LibreOffice on OS X, not on any other platform.
The cross-platform products require a stable behavior. The same keypress/macro command cannot give unpredictable results.
I tend to disagree. I think even cross-platform products should as much as possible adhere to the conventions of the platform they run on. Because users of that platform will not compare the behavior of such software with behavior of the same software on a different platform. They will compare the behavior of such software with behavior of other software on the *same* platform in case there is a convention. For OS X user, it's of no use for the alt-arrow to behave consistently with Windows or other platforms they don't use. For OS X user, it's of great use for alt-arrow to behave the same as the rest of the system, which they do use and the way they are used to. And the same IMHO holds if you substitute "OS X" for "GNOME", "Windows", or any other platform. Note that on OS X, already many shortcuts behave differently because of text conventions - e.g. Ctrl+P does not start printing, but moves in text line up (in fact, a whole bunch of emacs shortcuts work in text components on OS X and therefore LO). Printing is instead done by Cmd+P. Because that's what the OS X user expects. Etc. I personally find the behavior of LO confusing exactly because I am used from other OS X apps to the OS X convention of what alt-arrow means. Not because the convention is "better" in any way. But because it is consistently used by OS X apps, Apple and non-Apple ones, and I am used to such behavior. And I don't care how LO behaves on other platforms as I don't use those platforms. So this is approximately how I think about it. Not cross-platform consistency, but platform consistency.
Is this behaviour new in 4.2? If not, then the version field needs to be adjusted.
Not sure if I agree. alt + right-arrow moves to beginning of the next word. If you end on the word you are in or end at the start of the next word is just a design choice. It does neither improve nor degrade a workflow. Boris, do you know if this is a recommendation in some Apple Design Guideline? If so, could you link to that? Just checked and indeed all other softwares behave as you describe, so for the sake of consistency this should be changed. Not sure if this goes for all platforms or only OS X, though. Khaled, this behavior is not new to LO 4.2. It exists already in 4.1.1.2. Not sure about older versions but I'd guess they behave the same.
Hello James, now I looked into the OS X HIG and found this: Shift-Alt-right arrow: Extend selection to the end of the current word, then to the end of the next word. It's at https://developer.apple.com/library/mac/documentation/userexperience/Conceptual/AppleHIGuidelines/KeyboardShortcuts/KeyboardShortcuts.html#//apple_ref/doc/uid/TP40002725-SW2 While this is not "Alt-right arrow" but that with Shift added, it can be deduced from that how "Alt-right arrow" behaves - it should move to the end of the current word, then to the end of the next word, i.e. the cursor is at the end of some word after that action.
Confirmed in LibreOffice (Dev) 4.4.0 alpha1 under Mac OS X 10.10 (Yosemite) x86-64
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.