Hi Adam,
Ihor Radchenko <yantar92@posteo.net> writes:
Adam Porter <adam@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?