Provide org-insert-subitem

Provide org-insert-subitem

[Dmitrii Korobeinikov]

[-- Attachment #1: Type: text/plain, Size: 205 bytes --]

In short:
org-insert-heading -> org-insert-subheading
org-insert-todo-heading -> org-insert-todo-subheading
org-insert-item -> ?

Maybe should provide org-insert-subitem for consistency?

Regards,
Dmitrii

[-- Attachment #2: Type: text/html, Size: 307 bytes --]

Re: Provide org-insert-subitem

[Bastien]

Hi Dmitrii,

Dmitrii Korobeinikov <dim1212k@gmail.com> writes:

> In short:
> org-insert-heading -> org-insert-subheading
> org-insert-todo-heading -> org-insert-todo-subheading
> org-insert-item -> ?
>
> Maybe should provide org-insert-subitem for consistency?

`org-insert-subheading' and `org-insert-todo-subheading' are not used
anywhere in Org's code.  Do you them?  How?

I'm more inclined to delete these commands since they have no binding
than to add an `org-insert-subitem'.

Hitting <M-RET> then <M-right> seems swift and handy enough.

WDYT?

-- 
 Bastien

Re: Provide org-insert-subitem

[Dmitrii Korobeinikov]

Hi, Bastien,

> `org-insert-subheading' and `org-insert-todo-subheading' are not used
> anywhere in Org's code.  Do you them?  How?

I use them as intended: for convenience. Basically, I have a binding for this:

  (defun my/insert-heading ()
    (interactive)
    (end-of-line)
    (cond
     ((string-match (rx (and bol (0+ white) "- [")) (thing-at-point
'line t)) (command-execute 'org-insert-todo-heading))
     ((string-match (rx (and bol (0+ white) "-")) (thing-at-point
'line t)) (command-execute 'org-insert-item))
     (t (if (my/org-heading-collapsed-p) (evil-open-below 1))
(command-execute 'org-insert-heading) (evil-normal-state))))

and a similar function for sub-things. This makes it very easy to
insert (sub)headings/items/todo-items, all with just two bindings.

> Hitting <M-RET> then <M-right> seems swift and handy enough.

Sometimes that would have to be <M-RET> <M-RET> <M-right> when the
items in the list are seperated with a newline. That's an awful lot of
combinations for such a basic task, which I do quite often.

> WDYT?

To me, these functions seem fundamental enough to warrant the
according out-of-the-box experience.

Best,
Dmitrii

вс, 2 февр. 2020 г. в 13:49, Bastien <bzg@gnu.org>:
>
> Hi Dmitrii,
>
> Dmitrii Korobeinikov <dim1212k@gmail.com> writes:
>
> > In short:
> > org-insert-heading -> org-insert-subheading
> > org-insert-todo-heading -> org-insert-todo-subheading
> > org-insert-item -> ?
> >
> > Maybe should provide org-insert-subitem for consistency?
>
> `org-insert-subheading' and `org-insert-todo-subheading' are not used
> anywhere in Org's code.  Do you them?  How?
>
> I'm more inclined to delete these commands since they have no binding
> than to add an `org-insert-subitem'.
>
> Hitting <M-RET> then <M-right> seems swift and handy enough.
>
> WDYT?
>
> --
>  Bastien

Re: Provide org-insert-subitem

[Adam Porter]

Bastien <bzg@gnu.org> writes:

> `org-insert-subheading' and `org-insert-todo-subheading' are not used
> anywhere in Org's code.  Do you them?  How?
>
> I'm more inclined to delete these commands since they have no binding
> than to add an `org-insert-subitem'.
>
> Hitting <M-RET> then <M-right> seems swift and handy enough.

Please do not delete org-insert-subheading!  I use it every day and have
for years.  :) It would be much less convenient to have to use two
commands.

BTW, in my version of Org, org-insert-subheading works on both list
items and subheadings, so there's no need for a separate
org-insert-subitem command:

  Insert a new subheading and demote it.
  Works for outline headings and for plain lists alike.

Re: Provide org-insert-subitem

[Bastien]

Adam Porter <adam@alphapapa.net> writes:

> Please do not delete org-insert-subheading!

Done :)

I still find it strange to keep functions that are used nowhere in the
Org's core--except of course for functions that explicitely mention as
usable by the user (e.g. `org-clock-persistence-insinuate'.)

I'd rather have these functions stored in a org-utils.el library for
those who care.

This is not urgent, of course, we can have this discussion later on.

-- 
 Bastien

Re: Provide org-insert-subitem

[Adam Porter]

Hi Bastien,

Bastien <bzg@gnu.org> writes:

> I still find it strange to keep functions that are used nowhere in the
> Org's core--except of course for functions that explicitely mention as
> usable by the user (e.g. `org-clock-persistence-insinuate'.)
>
> I'd rather have these functions stored in a org-utils.el library for
> those who care.

I'm not sure what you mean about functions mentioned as usable by the
user.  org-insert-subheading is an interactive command, so it's
explicitly usable by the user.  And it's in org.el, so it's in Org's
"core", right?  I guess we're thinking in different terms.

Inserting a subheading or subitem is a very common operation in an
outlining and list-making tool, so it would seem like a significant
regression to remove it.

I'm not opposed to reorganizing the code, of course, as long as it
remains loaded as a command when org-mode is activated.

Re: Provide org-insert-subitem

[Corwin Brust]

[-- Attachment #1: Type: text/plain, Size: 1121 bytes --]

Hi,

On Wed, Feb 12, 2020, 15:28 Adam Porter <adam@alphapapa.net> wrote:

> Hi Bastien,
>
> Bastien <bzg@gnu.org> writes:
>
> > I still find it strange to keep functions that are used nowhere in the
> > Org's core--except of course for functions that explicitely mention as
> > usable by the user (e.g. `org-clock-persistence-insinuate'.)
>

[snip]

And it's in org.el, so it's in Org's
> "core", right?  I guess we're thinking in different terms.
>
> Inserting a subheading or subitem is a very common operation in an
> outlining and list-making tool, so it would seem like a significant
> regression to remove it.
>

I think there's an implied -and usually misleading‐ correlation between the
importance of a function and the count of self-references -meaning uses in
the defining package- shown from help buffers.    It would be cool to see
uses tracked as we byte-compile or something.

I'm not opposed to reorganizing the code, of course, as long as it
> remains loaded as a command when org-mode is activated.
>

I'm a fan of interactive methods in obvious, easy to reach places.

[-- Attachment #2: Type: text/html, Size: 2083 bytes --]

Re: Provide org-insert-subitem

[Bastien]

Hi Adam,

First of all, don't be afraid, I don't have a grand plan for "cleaning
up" things.

> I'm not sure what you mean about functions mentioned as usable by the
> user.  org-insert-subheading is an interactive command, so it's
> explicitly usable by the user.

Yes, org-insert-subheading is interactive and usable and in Org's core
but how can a user *discover* this command?

There is no keybinding for it and no mention in the manual.  Even as a
function, it is not even used in Org codebase.

The ways I can see for a user to discover this command is by trying to
complete M-x org-insert TAB or by reading Org's code (or other code in
the wild using it.)

So to me it's a "utility" command: something that Org does not depend
on, something that provides a useful feature, but not useful enough to
have a keybinding in Org's core or to be used as a function in Org's
core.

> And it's in org.el, so it's in Org's
> "core", right?  I guess we're thinking in different terms.

Well, my thinking is not about core vs not-core, it is more on how to
advertize such commands and functions.  I would recommand putting them
in org-utils.el but I'm not sure.  And yes, I'm not entirely convinced
such a library, if it existed, should live in Org's core :)

Best,

-- 
 Bastien

Re: Provide org-insert-subitem

[Adam Porter]

Bastien <bzg@gnu.org> writes:

> First of all, don't be afraid, I don't have a grand plan for "cleaning
> up" things.

Don't worry, I trust you.  :)  Org wouldn't be what it is today without
your work, and I'm grateful for how much time you've been putting into
improving Org lately.

>> I'm not sure what you mean about functions mentioned as usable by the
>> user.  org-insert-subheading is an interactive command, so it's
>> explicitly usable by the user.
>
> Yes, org-insert-subheading is interactive and usable and in Org's core
> but how can a user *discover* this command?
>
> There is no keybinding for it and no mention in the manual.  Even as a
> function, it is not even used in Org codebase.
>
> The ways I can see for a user to discover this command is by trying to
> complete M-x org-insert TAB or by reading Org's code (or other code in
> the wild using it.)

I guess what happened here is that I found that command years ago,
probably from either reading someone else's config online or, as you
say, using completion (I discover so many things using Helm
completion--I'm constantly using "C-h f org-" when working on
Org-related code).  Then I bound it to S-RET in my config, and I've been
using it ever since.  To me it feels like just as much a part of Org as
any other Org command.

> So to me it's a "utility" command: something that Org does not depend
> on, something that provides a useful feature, but not useful enough to
> have a keybinding in Org's core or to be used as a function in Org's
> core.

What if we document it in the manual?  For example, in section 2.5,
"Structure editing", we have:

    `M-<RET>'     (`org-insert-heading')
         Insert a new heading/item with the same level as the one at point.

    `C-<RET>'     (`org-insert-heading-respect-content')
         Insert a new heading at the end of the current subtree.  

    `M-S-<RET>'     (`org-insert-todo-heading')
         Insert new TODO entry with same level as current heading.  See
         also the variable `org-treat-insert-todo-heading-as-state-change'.  

    `C-S-<RET>'     (`org-insert-todo-heading-respect-content')
         Insert new TODO entry with same level as current heading.  Like
         `C-<RET>', the new headline will be inserted after the current
         subtree.  

What if we add:

    `S-<RET>'     (`org-insert-subheading')
         Insert a new subheading and demote it.
         Works for outline headings and for plain lists alike.

Note that I also propose binding it to S-<RET>.  It seems that, by
default, that key is currently bound in Org buffers to
org-table-copy-down:

    Copy the value of the current field one row below.

That's surely a useful function, but I feel like it probably isn't
widely used enough to deserve to be bound to S-<RET> in all contexts.
Of course, frequent users of this command, feel free to correct me, lest
I be a hypocrite.  ;)

If that seems agreeable, then I'd also propose renaming the command
(preserving its old name in an alias, of course) to something which
would not imply that it only works in outlines, perhaps
org-insert-subitem or org-insert-demoted.

In the longer term , perhaps we could make a new, contextual command
that would call one command in tables and another command in non-table
contexts.  If there were a clever way we could make similar, roughly
corresponding actions in both tables and tree structures use the same
bindings contextually, that might be useful.  I think it would be
reasonable, because if point is in a table, the user probably won't want
to insert a new outline heading in the middle of it.

What do you think?  Thanks.

Re: Provide org-insert-subitem

[Bastien]

Hi Adam,

Adam Porter <adam@alphapapa.net> writes:

> What do you think?

I think that's a good idea to promote org-insert-subheading either by
binding it to a key or another way.

I already have some drafty code that might touch things in this (very
sensible) area, so if you don't mind, I'll come back to the details of
your suggestions when I can articulate them with the few ideas I have
in mind.  And after 9.4 is out.

But yes, there is room for enhancements here.

Don't hesitate to bump this thread in a few weeks if I don't share my
ideas since then.

Best,

-- 
 Bastien

Re: Provide org-insert-subitem

[Adam Porter]

Hi Bastien,

> I think that's a good idea to promote org-insert-subheading either by
> binding it to a key or another way.
> 
> I already have some drafty code that might touch things in this (very
> sensible) area, so if you don't mind, I'll come back to the details of
> your suggestions when I can articulate them with the few ideas I have
> in mind.  And after 9.4 is out.
> 
> But yes, there is room for enhancements here.
> 
> Don't hesitate to bump this thread in a few weeks if I don't share my
> ideas since then.

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?  =)

Thanks,
Adam

0: https://yhetil.org/orgmode/875zg9trjo.fsf@bzg.fr/

Re: Provide org-insert-subitem

[Ihor Radchenko]

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 ;)
Would you be interested to submit a patch?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

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

Re: Provide org-insert-subitem

[Ihor Radchenko]

Bastien Guerry <bzg@gnu.org> writes:

>>> 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 already "copy down" a table cells, so I'm really suggesting a
> generalization of the current keybinding.

This makes sense.

> - S-RET on a list item calls `org-insert-subitem`, a new command.

Did you mean `org-clone-item'?

> - 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.
>
> I like C-M-RET better than S-RET because inserting a subheading is
> like a "subkey" or inserting a heading.

I tried to play around a bit with various flavours of X-<RET> commands
and I am not sure if I like C-M-RET:

1. For org-insert-heading, we have multiple variants that allow
   inserting heading at point, after current subtree, and the same
   variants for TODO heading. We don't have enough key combinations left
   to allow all the equivalents for subheadings.

2. With `org-cycle-level-after-item/entry-creation' set to t (default),
   it is actually very easy to create a subheading/subitem using the
   available C/M-[S]-<RET> commands. Just do M-<RET> <TAB>. And the same
   will work for inserting todo headings.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: Provide org-insert-subitem

[Adam Porter]

Hi Bastien, Ihor,

On 12/9/23 11:53, Bastien Guerry wrote:
> 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?

Not that I necessarily object, but that seems like a lot of new things 
to me.  The immediate, simple benefit I seek is provided by this code in 
my config now, binding it to "S-<return>" in org-mode-map:

   (defun ap/org-shift-return (&optional arg)
     "Call `org-insert-subheading' or `org-table-copy-down'."
     (interactive "p")
     (cond ((org-at-table-p)
            (org-table-copy-down arg))
           (t
            (org-insert-subheading arg))))

The "C-M-RET" binding doesn't feel quite right to me.  Using "shift" 
feels like a mnemonic for "sub", whereas "C-M" seems like it should do 
something much less frequently used, since it requires two modifiers.

Ihor also made some good points in his message about the combinations of 
commands to insert before/after, with/without TODO, etc, and that 
"M-<RET> <TAB>" is already a quick way to insert a subheading (I wasn't 
aware of the option `org-cycle-level-after-item/entry-creation').  So 
maybe this idea of mine isn't as important as I thought.  :)

Thanks,
Adam

Re: Provide org-insert-subitem

[Bastien]

Ihor Radchenko <yantar92@posteo.net> writes:

>> S-RET already "copy down" a table cells, so I'm really suggesting a
>> generalization of the current keybinding.
>
> This makes sense.
>
>> - S-RET on a list item calls `org-insert-subitem`, a new command.
>
> Did you mean `org-clone-item'?

Yes, sorry (`org-clone-item' is better than `org-item-copy-down', the
other idea that comes naturally.)

>> - 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.
>>
>> I like C-M-RET better than S-RET because inserting a subheading is
>> like a "subkey" or inserting a heading.
>
> I tried to play around a bit with various flavours of X-<RET> commands
> and I am not sure if I like C-M-RET:
>
> 1. For org-insert-heading, we have multiple variants that allow
>    inserting heading at point, after current subtree, and the same
>    variants for TODO heading. We don't have enough key combinations left
>    to allow all the equivalents for subheadings.
>
> 2. With `org-cycle-level-after-item/entry-creation' set to t (default),
>    it is actually very easy to create a subheading/subitem using the
>    available C/M-[S]-<RET> commands. Just do M-<RET> <TAB>. And the same
>    will work for inserting todo headings.

I'm not sure I follow the reasoning here: do you say that we don't
need to find a keybinding for `org-insert-subheading/subitem' because
it is already easy enough to insert a subheading/item using a certain
combinaison of commands?

Or do you suggest we need to find another prefix than "C-M-"? Which
one?

What matter the most to me here is the consistency of commands, but if
the keybindings can reflect that, all the better.

-- 
 Bastien

Re: Provide org-insert-subitem

[Bastien]

Hi Adam,

Adam Porter <adam@alphapapa.net> writes:

> The "C-M-RET" binding doesn't feel quite right to me.  Using "shift"
> feels like a mnemonic for "sub", whereas "C-M" seems like it should do
> something much less frequently used, since it requires two
> modifiers.

I agree that S- suggests "sub".

I've been playing around with C-RET, M-RET, S-RET and I do believe
there is room for improvement here, along with a dedicated keybinding
for `org-insert-subheading/subitem'.  I will refine my proposal later
on.

> Ihor also made some good points in his message about the combinations
> of commands to insert before/after, with/without TODO, etc, and that
> "M-<RET> <TAB>" is already a quick way to insert a subheading (I
> wasn't aware of the option
> `org-cycle-level-after-item/entry-creation').  So maybe this idea of
> mine isn't as important as I thought.  :)

Even if we end up not binding a new key for `org-insert-subheading',
it will be good to add org-clone-item and org-insert-subitem and
perhaps to improve bindings in this area. I will think again about
this.

Thanks!

-- 
 Bastien

Re: Provide org-insert-subitem

[Ihor Radchenko]

Bastien <bzg@gnu.org> writes:

>> 1. For org-insert-heading, we have multiple variants that allow
>>    inserting heading at point, after current subtree, and the same
>>    variants for TODO heading. We don't have enough key combinations left
>>    to allow all the equivalents for subheadings.
>>
>> 2. With `org-cycle-level-after-item/entry-creation' set to t (default),
>>    it is actually very easy to create a subheading/subitem using the
>>    available C/M-[S]-<RET> commands. Just do M-<RET> <TAB>. And the same
>>    will work for inserting todo headings.
>
> I'm not sure I follow the reasoning here: do you say that we don't
> need to find a keybinding for `org-insert-subheading/subitem' because
> it is already easy enough to insert a subheading/item using a certain
> combinaison of commands?

> Or do you suggest we need to find another prefix than "C-M-"? Which
> one?

I mean that it seems to be easy to insert subheading/subitem already.

You can try:

* Heading<point>
M-RET TAB

or

* Heading<point>
C-S-RET TAB

or

- item<point>
M-RET TAB

We even have this documented in the Structural Editing section of the
manual:

‘<TAB>’ (‘org-cycle’)
     In a new entry with no text yet, the first ‘<TAB>’ demotes the
     entry to become a child of the previous one.  The next ‘<TAB>’
     makes it a parent, and so on, all the way to top level.  Yet
     another ‘<TAB>’, and you are back to the initial level.

Probably, we should mention "subitem/subheading" words in the index or
find some other way to emphasize that it is possible to demote
subheading with TAB.

> What matter the most to me here is the consistency of commands, but if
> the keybindings can reflect that, all the better.

For me, it is important to keep consistency of the keys as well - these
are the core Org keys, and they should be as intuitive as possible.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>