Select sibling syntax node should not select parent node's sibling

[lboklin]

Summary

Trying to select a non-existing sibling syntax node, the selection escapes the current scope to select a sibling of the parent node. This can be a source of frustration as (especially for visually complex languages where it's not always immediately visually obvious how many movements are required to get to where you're going) navigating between siblings sometimes involve repeated, imprecise movements; if you accidentally move too far and leave the scope, you have to move back to the parent node and re-enter it, starting from the first child node again. If the scope contains many nodes it can involve a significant number of movements to find your way back.

I would expect Alt-p/Alt-n (move to prev/next sibling syntax node) to stop at the beginning/end of current scope depth, or alternatively loop back to the first/last sibling, to be consistent with other movements when reaching first/last match in the document. This way, if you move too far you only have to perform one corrective movement in the opposite direction.

If I do intend to select a sibling node of the parent, I would do so explicitly with Alt-o (expand selection to parent syntax node) followed by Alt-p/Alt-n.

Reproduction Steps

I tried this:

Haskell example:

thing h =
  let xs = [0.0, 0.05 .. 1.0]
      cs = xs & fmap (\c -> c * pi / 2 & cos)
      vsSq = xs & fmap (\s -> s * s * 100)
   in zip vsSq cs
        & fmap (\(vSq, c) -> replicate (c * vSq & round) '-')
        & dup
        & first reverse
        & uncurry h
        & unlines
        & putStr

dup x = (x, x)

I intend to select the last function, putStr, but accidentally hit Alt-n one too many times.

I expected this to happen:

Either nothing or selection would move to zip vsSq cs & ... & unlines so that I can hit Alt-p once to correct my movement.

Instead, this happened:

Selection moves to dup x = (x, x) two lines below. Alt-p selects the entire thing h = ... definition, requiring these movements to get back to putStr:
Alt-i
Alt-n
Alt-n
Alt-n
Alt-i
Alt-n
Alt-i
Alt-n
Alt-i
Alt-n
Alt-n

Helix log

No response

Platform

Linux

Terminal Emulator

alacritty 0.10.1

Helix Version

helix 22.05 (27609f5)

[the-mikedavis]

This was intentional behavior in the original PR: #1495

Because I didn't like getting 'stuck' when reaching past the first/last child.

It can be a bit annoying though if it goes too high in the tree and it's hard to get back. Maybe that's more generally solved by #1596 though?

[lboklin]

It can be a bit annoying though if it goes too high in the tree and it's hard to get back. Maybe that's more generally solved by #1596 though?

That would certainly help in these situations. But even without the annoyance of getting losing your place, I feel the current behaviour is a bit unintuitive because it doesn't feel like it respects the tree structure. Maybe this behaviour could be configurable.

As an another alternative, perhaps it can retain the depth you were at as a "max depth" and automatically descend into any sibling nodes' children at the same depth? The downside of this is that you have less control over it and may have to resort to silly Alt-o,Alt-i to reset it.

[the-mikedavis]

With #2877, not ascending the tree might be better. I remember getting stuck a lot more before that change. Would you like to create a PR with the change to remove the ascending behavior? I'd like to try it out for a bit and see if I end up missing the ascend behavior.