Hi Adam, Ihor Radchenko <yanta...@posteo.net> writes:
> Adam Porter <a...@alphapapa.net> writes: > >> Well, it's been a few years since I forgot to bump this thread. [0] :) >> I just rediscovered it after wondering why the command >> org-insert-subheading still doesn't have a default binding. May we >> revisit this? I find myself wanting to insert a subheading almost every >> day, and I have to "M-x org-insert-subheading RET". >> >> Of course I could bind it myself, and in one of my configs I have, but I >> still think it deserves a default binding, even if it were to be a >> "smart" command that worked like org-table-copy-down when in a table and >> does org-insert-subheading otherwise (because I still think that "S-RET" >> is an obviously appropriate binding for this command). >> >> What do you think? =) > > I think that it still makes sense, even after all these years ;) +1! Thanks for reviving this thread. I would suggest a larger set of enhancements here: - S-RET on a heading copies down the heading. For that we would need a new command `org-clone-subtree' bound to S-RET that would immediately copy the heading at point. This command would accept a universal argument to allow for a number a clones and two universal arguments for adding a time shift. `org-clone-subtree-with-time-shift' would continue to be bound to `C-c C-x c' but would be really a call to `org-clone-subtree' - S-RET on a list item calls `org-insert-subitem`, a new command. - C-M-RET on a heading calls `org-insert-subheading', the existing command. - C-M-RET on a list item calls `org-insert-subitem', a new command. S-RET already "copy down" a table cells, so I'm really suggesting a generalization of the current keybinding. I like C-M-RET better than S-RET because inserting a subheading is like a "subkey" or inserting a heading. These improvements seem consistent. WDYT? -- Bastien Guerry
