https://bugs.documentfoundation.org/show_bug.cgi?id=98404
--- Comment #28 from Michael Spear <[email protected]> --- I almost filed another bug report for this issue. The defaults in Impress are maddening. Though not explicitly listed at <https://en.wikipedia.org/wiki/IBM_Common_User_Access>, I'm pretty sure that Ctrl+Shift+Home and Ctrl+Shift+End have been consistent since the Common User Access guidelines in the 1980s. Their behavior should be exactly as it is in Calc and Writer, and exactly as it was in earlier versions of Impress. IMO, it is also poor UX to say "clearing the shortcut mapping in Tools/Customize/Keyboard reverts to the standard/expected behavior". - First of all, that means there is an standard/expected behavior. Why default to something else? - Second, it leaves people thinking that they can't get the expected behavior, because blank should mean "this key combination does nothing". Emacs got this right: if a key can cause a behavior, there must be a function to express that behavior. Ctrl-Home, Ctrl-End, Shift-Home, Shift-End, etc. should all have a function or series of functions (e.g., Ctrl-Shift-Home gets the sequence (set-mark-command) (beginning-of-buffer)). Yes, this means the function list will be extremely long. But with reasonable defaults, most users won't ever open that setting, and those who do will appreciate the completeness. And for those of us who need to automate keyboard configuration for non-power users who we are trying to migrate away from non-free office products, the expression of these issues in registrymodifications.xcu is counterintuitive. The edits for these shortcuts appear to be: <item oor:path="/org.openoffice.Office.Accelerators/PrimaryKeys/Modules/org.openoffice.Office.Accelerators:Module['com.sun.star.presentation.PresentationDocument']"><node oor:name="END_SHIFT_MOD1" oor:op="remove"/></item> <item oor:path="/org.openoffice.Office.Accelerators/PrimaryKeys/Modules/org.openoffice.Office.Accelerators:Module['com.sun.star.presentation.PresentationDocument']"><node oor:name="HOME_SHIFT_MOD1" oor:op="remove"/></item> "remove" is hardly the right word for the behavior being achieved. The file format is fundamentally not declarative. -- You are receiving this mail because: You are the assignee for the bug.
