vim-orgmode
vim-orgmode copied to clipboard
Bad heading structure confuses orgmode
With the following file, m]]
on "another thing" moves it below "higher level" (m[[
does not move it back up):
* toplevel heading
important
more
*** TODO check out orgmode :bla_bal_bla:
some stuff <0013-10-08>
sadf <2013-10-16 Wed>
a [2013-10-16 Wed]
*** another thing
a <2013-10-16 Wed>
m]] here moves me below the following heading
** TODO higher level :another:
other stuff <2013-10-16 Wed>
With a second-level heading inserted, it does not:
* toplevel heading
important
more
** is this a heading? (new 2nd-level heading)
*** TODO check out orgmode :bla_bal_bla:
some stuff <0013-10-08>
sadf <2013-10-16 Wed>
a [2013-10-16 Wed]
*** another thing
a <2013-10-16 Wed>
m]] here does nothing
** TODO higher level :another:
other stuff <2013-10-16 Wed>
That's not a bug but a feature :-). Broken heading structures are "broken" and therefore the behavior is undefined. There is logic in vim-orgmode that treats the level 3 heading another thing
to be on the same level as higher level
. It convenient by complicates everything. I'm thinking about throwing out this logic so that it will not be possible to move around broken headings at all.
Your explanation sounds sensible, but I can't really relate it to the issue ;-)
The first example starts with heading levels 1,3,3,2 (broken, there's a missing level 2 after the 1), and changes to 1,3,2,3 (still weird, but no more broken). The second example starts with heading levels 1,2,3,3,2 (correct), and should change to 1,2,3,2,3 (still correct).
There is logic in vim-orgmode that treats the level 3 heading another thing to be on the same level as higher level.
How can a level 3 heading be on the same level as a level 2 heading?
I'm sure I just don't understand properly ... I haven't actually been using vim-orgmode :blush:
Oh, the tree it's not a simple layering relation. It's a parent-children relation tree. 12332
means the first 2
has two children 3
, second 2
has none. These children 3
do not belong to the second 2
, so they are not supposed to go below it.
The reason you were able to move in the first example is that for 1332
, two 3
s do not have a proper parent, so they were treated as the direct children of 1, same as 2
, thus they can move below 2
. But once down, they will be recognized as children of 2
and only able to move within the children region of 2
henceforth. This function is for rearanging sequence among siblings, not rearanging paranting relation. You don't want to mess-up the relation-tree by too many repeat times of rearanging adjustment(eg. 4m]]
on a 3
), right? To manually rearange paranting relation, you can always fold a 3
and dd
it then paste it below a parent you think it belongs to.
Thanks @Ron89, this is exactly the case. So I was talking about removing the logic that treats the first two level 3
headings as children of the level 1
heading all together. It's nice of Emacs org-mode to implement this workaround for broken documents but it makes things much more complicated by introducing these kind of corner cases.
I'll leave the issue open for the behavior to be changed.
Hmm, making it simple is good and all. But on the other hand, there are user cases when they want to rearrange the structures, leaving temporary orphan children headings. Excluding exception cases could make user feel limiting in those cases. That being said, There's nothing wrong with try and see if it's better. And instead of outright removing the workaround, how about adding auto-fixing mechanism, adding placeholder parents for orphaned headings when cleaning up dirty structure? It'll making the experience less confining, conceptually. What do you think?
And no matter how the change is going to be, I suggest placing the adjusted behavior into some testing branches to test it out first.
I'm not yet convinced. The user can always rearrange things using regular vim commands. I agree that there should at least be good feedback for the user if things are broken.