I think this has just started to happen? When I Delete Row, the cursor jumps up, whereas I think the default should be to jump down. I am more likely to want to delete a few child rows than a child and its parent. For example, i delete test1, which first deletes the text (that’s fine), and then when i delete the empty row, the cursor jumps to Test, rather than to test2.
For me Delete Row is working as you suggest it should. Siblings are deleted before parents. And I don’t think I have changed much related code.
I did change “Row: Text Delete” recently and maybe that’s what is causing the change for you? Maybe you have a custom keybinding that replaces normal delete row with the text variant?
that’s it. it was a custom keybinding. now the default works as i want it to. thanks
1 Like
I understand better what i want.
For Row: Text Delete, I would like the cursor to walk not up, but down (i.e. if i delete test1, i want the cursor to go to test2, then test3). Currently, the cursor walks up.
(i’m using Bike’s default keybinding)
Also, i think it might work better if Row: Text Delete were to only delete a single row, even if it is a Parent with folded Children (given that Row: Block Delete also exists). This would mean that deleting a Parent row with folded Children would expose the Children, which i think is safer.
I’ve updated text delete in latest release to work more like you suggest, but have kept deletion of folded rows as part of behavior. Bike 2.0 (Preview 301)
thanks for this. one more query though.
using Row:Text Delete on an unfolded parent leaves the children, which is fine, but it also automatically causes a folded parent above to unfold (presumably because the orphaned children need a parent? (this is getting dark).
starting with this
test 1 folded
if i apply row:text delete to test2, test1 unfolds.
If test1 isn’t big, it’s not a big problem, but test1 might contain a lot of children and then one has unfolded a huge amount of text.
i think a better behaviour would be to leave test1 folded even with orphaned children below
I think we are getting into the complexity of why I made block based commands the default in Bike 2.0! 
They are more constraining, but they are also much easier to reason about for both programmer and user.
To me that would be more confusing. Wouldn’t user just come to the conclusion that those trailing rows were deleted with the parent then? To me revealing and selecting seems the clearest approach. It’s true it’s disruptive if the expanded branch is large, but I don’t see any way around that isn’t worse in my opinion.
1 Like
okay, i can see that. i think i’ll use backspace a bit more.
1 Like