> for Home/End you must press
> Fn+left/right arrow, which generally does nothing on macOS.
> 
> Is this WAI?


From https://support.apple.com/en-us/HT201236

Fn–Left Arrow: Home: Scroll to the beginning of a document.
Fn–Right Arrow: End: Scroll to the end of a document.(In reply to Dan Dascalescu from comment #0)

In writer everything works as expected I think:

alt + left / right: move by word
cmd + left / right: start / end of line
fn + left / right: beginning / end of document

calc cell edit mode:

cmd + left / right: move by word
alt + left / right: change column width
fn left / right: start / end of line

Then there is also non cell edit mode and the keys do something else yet again.

Setting to new as confirming the inconsistency. But this needs input - adding needsUXEval.

And the expectation is probably to do the same as Microsoft with

cmd+left/right: begin/end of line
opt+left/right: begin/end of word
cmd+up/down: begin/end of paragraph (we use with opt)
fn+up/down: page up/down

(selecting when shift is being pressed)

We define for example

<node oor:name="LEFT_MOD1" oor:op="replace">
   <prop oor:name="Command">
       <value xml:lang="x-no-translate">I10N SHORTCUTS - NO TRANSLATE</value>
       <value xml:lang="en-US">.uno:GoToPrevWord</value>
   </prop>
</node>

in officecfg/registry/data/org/openoffice/Office/Accelerators.xcu with MOD1 being Ctrl/Cmd.

On Windows/Linux you move word-wise with ctrl+left. So what we need is to change the commands/accelerator combination like in

<node oor:name="F_MOD1_MOD2" oor:op="replace">
    <value xml:lang="en-US" install:module="macosx">.uno:SearchDialog</value>
...
<node oor:name="H_MOD1" oor:op="replace">
    <prop oor:name="Command">
       <value xml:lang="en-US" install:module="unxwnt">.uno:SearchDialog</value>

Very much welcome for the macOS users.

I did some debugging and it appears to me that macOS standard key bindings are transposing key shortcuts like this before our code sees them.

For example, Command-Left when pressed is the macOS standard "end of line" key shortcut so instead of receiving a "key down" event with the Mod1 and com::sun::star::awt::Key::LEFT pressed, LibreOffice receives receives an "action" callback that our code translates to com::sun::star::awt::Key::MOVE_TO_END_OF_LINE.

So I assume we just need to duplicate the applicable key shortcuts that are already in the Calc configuration files and replace LEFT_MOD1/RIGHT_MOD1/etc. with MOVE_TO_BEGIN_OF_LINE/MOVE_TO_END_OF_LINE/etc. Or is there a simpler way to edit the existing entries?

Hi Heiko,
Could you please explain why it's a high priority bug ? IMHO, it doesn't make sense to set an easyhack to high because it might take a lot of time until a newcomer fixes it. If it's really a high priority bug you should consider to fix it yourself asap

MacOS users have continuously switch from cmd+left, working on all/most other tools, to alt+left. Super annoying => high. Feel free to revert.

(In reply to Heiko Tietze from comment #7)
> MacOS users have continuously switch from cmd+left, working on all/most
> other tools, to alt+left. Super annoying => high. Feel free to revert.

Feel free to revert what ?

(In reply to Heiko Tietze from comment #4)
> We define for example
> 
> <node oor:name="LEFT_MOD1" oor:op="replace">
>    <prop oor:name="Command">
>        <value xml:lang="x-no-translate">I10N SHORTCUTS - NO TRANSLATE</value>
>        <value xml:lang="en-US">.uno:GoToPrevWord</value>
>    </prop>
> </node>
> 

I did some experimenting and replaced all of the "LEFT_MOD1" entries in main.xcd with "MOVE_TO_BEGIN_OF_LINE" which is a key constant defined in Key.idl. But that throws and an exception and crashes LibreOffice.

So, my guess at this point is that we don't have the ability to add handlers in main.xcd for macOS' special "action" keys even though such keys are defined in Key.idl.

Since Writer and Impress appear to move to the start or end of a line properly, I will see if I can find how either of those modules handle the MOVE_TO_BEGIN_OF_LINE and MOVE_TO_END_OF_LINE special keys.

I forgot to mention that in Writer, Calc, and Impress, any Command-Left/Right keys are being mapped to the following in svtools/source/misc/acceleratorexecute.cxx so I am guessing that Calc is overriding this mapping somewhere:

        case css::awt::Key::MOVE_TO_BEGIN_OF_LINE:
            return ".uno:GoToStartOfLine";
        case css::awt::Key::MOVE_TO_END_OF_LINE:
            return ".uno:GoToEndOfLine";

(In reply to Patrick Luby from comment #9)
> I did some experimenting ... But that throws and an exception and crashes LibreOffice.
So apparently not easy hackable.

(In reply to Heiko Tietze from comment #11)
> So apparently not easy hackable.

I agree. What is interesting is that when editing text in Impress, editeng/source/editeng/editeng.cxx is receiving MOVE_TO_BEGIN_OF_LINE/MOVE_TO_END_OF_LINE key events when Command-Left/Right are pressed.

But when editing a cell in Calc, the same code receives KEY_LEFT/KEY_RIGHT events. I know that vcl is receiving native MOVE_TO_BEGIN_OF_LINE/MOVE_TO_END_OF_LINE events so I will need to do more debugging to find where the native MOVE_TO_BEGIN_OF_LINE/MOVE_TO_END_OF_LINE events are converted to KEY_LEFT/KEY_RIGHT events.

OK. So I now see what is happening. vcl is trying to dispatch MOVE_TO_BEGIN_OF_LINE/MOVE_TO_END_OF_LINE events but when editing a cell, Calc rejects those events so vcl retries dispatching the last native event and the last event is the "untransformed" Command-Left/Right keys.

I launched Microsoft Excel (the unpaid Mac App Store version) and found that Command-Left/Right in Excel move only a word at a time left or right. So, I now suspect that Calc is rejecting these MOVE_TO_BEGIN_OF_LINE/MOVE_TO_END_OF_LINE events on purpose so that LibreOffice has the same behavior when editing cells as Microsoft Excel for macOS.

@Heiko Tietze I think we are back to the bug filer's original question: is copying Excel's behavior what we want? If yes, then we can close this bug. But if no, then let me know and I'll see if I can find the code that rejects these events in Calc only.

(In reply to Patrick Luby from comment #13)
> Is copying Excel's behavior what we want? If yes, then we can close this bug.
If you ask me, we should do better than MSO. Consistency on the OS-level is more important than to copycat MSO. Others may have different opinions. The goal would be to make customization possible and and if users want to change the default we should not hinder them.

If customization is not possible we better hide the command/s in the list (AccelConfig/MenuConfig...).

OK. I am not very picky about HIG compliance (the "G" stands for "guidelines" afterall) so I don't have any strong opinion about UI changes like this.

But after looking at Microsoft Excel's behavior, I can see how people might find the "move to next left/right chunk of the formula" useful. Maybe the UX/design committee needs to evaluate such a change?

I definitely won't implement any changes to the current behavior as I don't know how or where to implement new behavior. My skills are mostly limited to vcl and implementing I am having a very difficult time determine what would need to get the Calc code behavior to change. So far, I have only found that the toolbar cell editor and the "in place" editor within a cell have their own implementations and the toolbar cell editor doesn't seem to respond to any main.xcu changes.

(In reply to Patrick Luby from comment #15)
> But after looking at Microsoft Excel's behavior, I can see how people might
> find the "move to next left/right chunk of the formula" useful. Maybe the
> UX/design committee needs to evaluate such a change?
It's IMO consistency with the OS and we better compare with Pages or Numbers. Cmd+left/right goes to start/end of line, up/down to the document, alt+left/right to the word and up/down for the paragraph.

Doubt the UX committee has more input, rather the macOS users. I could start a poll but my point was to allow customization first of all (and have a sane default). Requires some insights to the code, apparently.