Feature request - Decouple org's keybindings from their functions

[mithraeum <mithraeum@protonmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2230 bytes --]

I'd like to request that org's keybindings be separated from the functions they use to do their work.

This would greatly ease the use of these functions by people who want to use their own keybindings rather than relying on keybindings that org provides.

The reason I ask is that recently I've been going through org-agenda.el and binding its functions in to my own hydras, in a way that makes sense to me and is compatible with my own pre-existing keybindings.  I've found that in many cases the default org keybindings are tightly integrated with their functionality.  In some cases it's possible to decouple them with some reverse-engineering effort, but in other cases it's virtually impossible without rewriting the function -- and even understanding how an org function does its work is often difficult.

One example of this is the "org-agenda" dispatcher function, which (for example) offers no clear way to independently invoke the "<" ("Buffer, subtree/region restriction") or ">" ("Remove restriction") commands.

Another example is the definition of org-agenda-custom-commands, which require the user to go through the org-agenda dispatcher to invoke their custom agenda views.  Those views would ideally be accessible by simple functions that the user could call directly any way they see fit.

As a user, it would make my life so much easier if I didn't have to delve deeply in to a menuing function's source code to figure out how it works so that I can bind something it does to a keyboard shortcut (or hydra) of my choice.

Ideally, each org menu's keybinding would be an exceedingly simple binding to a single function that should be just as easily invocable from user code as it is from org's own code.  It should not be buried in a mountain of logic and assumptions in the middle of a function that builds up a ton of state before the inner function is callable, as that would require the user to reproduce that state before they could use the function themselves.

Ultimately, I think it would be much, much cleaner for org to use a dedicated, well designed menuing package like hydra to do its menuing.  But simply decoupling org's keybindings from the functionality they invoke would be a great first step.

[-- Attachment #2: Type: text/html, Size: 2487 bytes --]