Feature request - Decouple org's keybindings from their functions

Feature request - Decouple org's keybindings from their functions

[mithraeum]

[-- 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 --]

Re: Feature request - Decouple org's keybindings from their functions

[Nicolas Goaziou]

Hello,

mithraeum <mithraeum@protonmail.com> writes:

> 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

Are you talking about Org a whole, or just Org agenda? All your examples
are about the latter. If it's about Org agenda, well, I'm afraid to say
there are so many things to fix there that keybindings are only the tip
of the iceberg.

> 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.

Hydra is very opinionated about what a menu is. It may not be a good
default. Also, it doesn't ship with Emacs. So Org cannot rely on it from
the start.

Regards,

-- 
Nicolas Goaziou

Re: Feature request - Decouple org's keybindings from their functions

[mithraeum]

On Tuesday, November 27, 2018 12:02 AM, Nicolas Goaziou <mail@nicolasgoaziou.fr> wrote:
>
> Are you talking about Org a whole, or just Org agenda? All your examples
> are about the latter. If it's about Org agenda, well, I'm afraid to say
> there are so many things to fix there that keybindings are only the tip
> of the iceberg.

I thought org-agenda was part of org.  It's org-agenda which I've been going through recently to bind in to hydras, so that's why I used it as an example.  I hope the principle of separating functions from bindings applies to the rest of org as well, though.

> Hydra is very opinionated about what a menu is. It may not be a good
> default. Also, it doesn't ship with Emacs. So Org cannot rely on it from
> the start.

I can understand how hydra not being shipped with Emacs would preclude it from being used by Org.  Maybe it could inspire the way Org handles menuing, however.  As opinionated as it might be, it's very flexible and powerful, and its keybindings and menus are clearly separated from the functions they invoke.

But if there is something even better and cleaner than hydra, I'd be all for it.

Re: Feature request - Decouple org's keybindings from their functions

[stardiviner]

Decoupling is not a good idea. Because it will let user define too much
keybindings. And User can define keybinding in Emacs easily. Emacs is
powerful for customization.

And user need convention for Org default keybindings so that when Org
users communications can know what he did. For example, when I said [C-c
C-c] in Org, Every Org users know it.

--
[ stardiviner ]
       I try to make every word tell the meaning what I want to express.

       Blog: https://stardiviner.github.io/
       IRC(freenode): stardiviner, Matrix: stardiviner
       GPG: F09F650D7D674819892591401B5DF1C95AE89AC3

Re: Feature request - Decouple org's keybindings from their functions

[Ihor Radchenko]

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

> Decoupling is not a good idea. Because it will let user define too much
> keybindings. And User can define keybinding in Emacs easily. Emacs is
> powerful for customization.

I disagree. It is against emacs philosophy.
It is one of the key features of emacs that users can redefine
keybindings if they need to (but do not have to do it).
I do not like loosing this feature without a strong reason. 

> And user need convention for Org default keybindings so that when Org
> users communications can know what he did. For example, when I said [C-c
> C-c] in Org, Every Org users know it.

You can as well say `M-x org-ctrl-c-ctrl-c` and be understood.

Best,
Ihor


stardiviner <numbchild@gmail.com> writes:

> Decoupling is not a good idea. Because it will let user define too much
> keybindings. And User can define keybinding in Emacs easily. Emacs is
> powerful for customization.
>
> And user need convention for Org default keybindings so that when Org
> users communications can know what he did. For example, when I said [C-c
> C-c] in Org, Every Org users know it.
>
> --
> [ stardiviner ]
>        I try to make every word tell the meaning what I want to express.
>
>        Blog: https://stardiviner.github.io/
>        IRC(freenode): stardiviner, Matrix: stardiviner
>        GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
>


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]