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