Unexpected behaviour when moving item up the hierarchy

As far as I can tell I’m running the latest of all the packages related to birch.
I pasted the contents of an earlier written text into a bml file. Then I started constructing a hierarchy.

  • item 1
  • item 2
  • item 3
  • item n

When I then tried promoting item 2 (using Shift+Tab) it behaved like thus:

  • item 1
  • item 3
  • item n
  • item 2

It did not just promote but also moved downward. It took a while before I understood what happend because my first interpretation was that it moved to the end of the document instead of being promoted. What I had expected would have been:

  • item 1
  • item 2
  • item 3
  • item n

I’d prefer the latter behaviour because otherwise I’d have to manipulate not just item 2 but also everything that I might want to associate with it. This would be to hard to keep track of in larger documents.

I would probably agree that the existing behaviour is logical but unfamiliar or unexpected.

Logical, because it doesn’t disrupt other parent-child relationships – One of my children gets promoted, but I don’t cease to be the parent of the remaining children.

Unfamiliar, and perhaps unexpected, because users of FoldingText, OmniOutliner etc, may not be used to seeing a request for a ‘leftward’ movement also triggering an additional ‘vertical’ movement.

There’s an inevitable tension here, of course, between the ‘sequence of lines’ model on the surface, and the deeper ‘tree’ model of the underlying nested structure, but perhaps convention and the probable intuitions of learners point to outdent entailing adoption of following peers as children, rather than entailing a physical leap downwards in the buffer ?

(Ergonomically, of course, its also easier, in case of second thoughts, for the user to reverse a purely ‘left-right’ movement than a ‘horizontal + vertical’ operation )

(And there’s a spectrum of responses to this tension – FT is more purely left-right than OmniOutliner, for example)

I agree. My preference is mostly based on familiarity. I could imagine a workflow around the current behaviour, but it requires me to easily indicate which children belong together. BTW: I seem to have lost a few of the keybindings ( something like T I) when I tried to upgrade. I will look into that later today.

They key for me here is reversibility.

In the current setup any move is reversible with other moves. If I changed the behavior like OmniOutliner then some moves can gather children, and you can’t “undo” that by doing other moves. I think with Birch this makes it possible to move things around quickly without the worry that you’ll mess up the hierarchy.

For your particular use case there are two commands that can help: birch-outline-editor:promote-child-items and birch-outline-editor:demote-trailing-sibling-items. At the moment they don’t have keyboard shortcuts setup for them, but you can set something up in Atom > Open Your Keymap.

When you have “item 2” selected you can do birch-outline-editor:demote-trailing-sibling-items, then “item 2” will have all those trailing siblings as it’s children. Then you can promote it and they will follow along as you wanted.

In the case of FoldingText it has both “text level” moves and “branch level moves”. The branch level moves worked just like Birch does now… but the text level moves only moved the direct selection (like a plain text editor) and so would have allowed you to promote “item 2” without having it’s vertical position shift.

It won’t be to hard to add “text style” move commands to Birch too, though I’m not sure if the added confusion is worthwhile or not. I have been thinking for instance that when in “text” mode moves should be on the text, and when in “item” mode they should be on the hierarchy… but I sorta suspect that would be confusing to anyone who’s not a dedicated outliner.

Differentiated commands does sound ideal, and of course cmd Z undo is always at hand.