Re: Contributing org-menu (using transient) to Orgmode?

[Jan Rehders <jan@sheijk.net>]

> Your package appears somewhat similar to
> https://github.com/kickingvegas/casual-suite

Yes, only the speed commands like functionality seems to be less common for the casual packages. I even considered renaming it to casual-org before I saw that all the casual packages are by the same person

> Maybe. I am not 100% sure about generic menu functionality, but we do
> have something similar for org-goto (help window) and org-speed-commands
> (org-speed-command-help). Using transient instead of these ad-hoc help
> menus could be beneficial. In particular, integration with
> org-speed-commands can be very helpful.
> 
> More generally, we have previously discussed the idea of generic help
> menu for major modes. See https://list.orgmode.org/orgmode/87a5oayblv.fsf@gmail.com/
> I personally like the idea of some kind of help menu, but I have doubts
> that transient is best-suited for the task. Ideally, help menus should
> help with the existing key bindings rather than introducing brand
> new. AFAIK, transient _always_ introduces new bindings.

I think which-key has been added to Emacs, that one seems like a good fit

>> - should something in Orgmode also have the modal editing part
>>  integrated? For me that part is the most useful as I can use the
>>  transient for nearly all editing tasks and the move into the tasks
>>  for commands whose shortcuts I keep forgetting
> 
> org-speed-commands

org-menu works on many more elements than headings. Table cells, list items, dates, normal text formatting, etc. See the transient-insert-suffix 'org-menu at the end of the file following :if blocks for conditional enabling commands for various elements. This is as ad-hoc as Orgmodes keybinding overloads depending on context (which might also be a good thing to generalise it, like some commercial text editors did/do)

> 
>> - would this need to be made more modular and extensible so it's
>>  different parts could be moved into the respective Orgmode parts
>>  (like column view features, etc.)?
> 
> I do not have a full picture of what you have in mind wrt integration
> with Org upstream and about the structure of your package. So, I cannot
> tell much on this.

This is more or less what I want to find out. It mostly depends on what Orgmode maintainers think is most useful or how this should change.

I imagine splitting it into several files which follow Org’s existing structure might make sense as well as making it easier to add new parts to it. I don’t know how to best do that, yet.

> wrt column view, I have doubts that transient can be very useful -
> column view uses overlay keymaps while transients are global.

org-menu has support for column view. It’s the only way I’ve ever succeeded in using it w/o having to look up all the bindings, again.

>> I'd be open to contributing this to Emacs/Orgmode but I'd also be
>> happy to keep maintaining it as a separate package. Only thing I
>> would like to avoid would be to strip parts of it's functionality as
>> then I'd need to fork my own package
> 
> This part is not fully clear to me. Do you mean that you are only
> willing to upstream the whole package, but not parts of it?

I’m willing to upstream it in any way. But w/o the speed keys functionality I think I would kind of fork it again for my personal use. Or better yet use to be added extension hooks to re-add it