Re: Provide org-insert-subitem

[Bastien Guerry]

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?

-- 
 Bastien Guerry