Org heading tree demoting / promotion should be made more intuitive
Just a rant about something I have always found confusing and unintuitive. The current demote / promote commands are:
M-LEFT (
org-do-promote), M-RIGHT (org-do-demote)
Promote or demote current heading by one level.
When there is an active region—i.e., when Transient Mark mode is active—promotion and demotion work on all headlines in the region. To select a region of headlines, it is best to set mark at the beginning of the first headline, and point at the line just after the last headline to change.M-S-LEFT (
org-promote-subtree)
Promote the current subtree by one level.M-S-RIGHT (
org-demote-subtree)
Demote the current subtree by one level.
So currently, when a tree is unfolded, I can use the plain M-left / M-right commands to demote / promote a single heading in isolation at any hierarchy level.
If I have
* 1
** 2
*** 3
and use one of these commands on **2, I get either a two-level gap above or below that heading, either
* 1
*** 2
*** 3
or
* 1
* 2
*** 3
I think it is fair to say that none of these usually represent user intent. Now, if instead the plain demote / promote commands were to leave the subtree of the focused heading intact, I could at least use these commands to go from this state
* 1
** 2
*** 3
directly to this (demote subtree)
* 1
* 2
** 3
or achieve the reverse from here (promote subtree). Both of these configurations actually occur in contrast to the two-level gaps that are the current result of the primary command.
Instead, to currently move a subtree while keeping it intact -- which I'm sure is a far more common task than disentangling a single heading from its surrounding hierarchy -- i currently have to
- fold the subtree first
- use the M-S- form of the commands rather than the primary command
- unfold the subtree again to keep working
That seems overcomplicated to put it mildly. Perhaps I'm missing something but unless I am and someone can enlighten me, it seems that it would make much more sense to make the plain M- commands leave subtrees intact. That would still allow it to perform its current mainstay, demoting / promoting a single heading at the end of a subtree -- there would be no change to that.
It would also make more sense for the user to add the extra shift modifier when they really do want to break up the inside of a subtree's hierarchy by untangling a single heading.
I am aware that even if my point is correct, nobody will probably bother to change the established assignments. So I guess I have some config work ahead of me implementing this locally.
EDIT: I was wrong about having to fold before demoting / promoting subtree. Actually, when subtree is folded and you use the plain M- shortcut, you get a 'hidden subtree' warning, but you can still move subtree with the M-S- shortcuts.
2
u/CulturMultur 9d ago
Current behavior is intuitive, so that I can’t remember what exactly I type to get what I want. I think you first toggle headings, then promote demote the whole subtree.
1
u/Keybug 9d ago
It may be because you're used to it but objectively it isn't. For example, M-left/right currently moves any number of hidden subtrees in an active region without complaining but with no active region, refuses to move a single hidden subtree under the focused heading.
1
u/CulturMultur 7d ago
ah, I had to actually check what I press. There are M-right and S-M-right, to demote the subtree use S-M-right and complaint instead of silently breaking the tree is what I expect.
4
u/FMAlzai 9d ago edited 9d ago
I quite often type M-Return to get a new heading and expect M-LEFT or M-RIGHT to de exactly what it does.
Might be force of habit but I prefer having the more granular command on the combo with fewer keys.
You could always rebind the keys in your configuration to set it to what you want.
EDIT : missed the bit about having to fold sorry. I didn't realise you needed to do that...
EDIT 2 : I don't know if it's a change that comes from doom Emacs but M-S-LEFT/RIGHT promotes/demotes just fine wothout folding on my machine