Section navigation is "inconsistent" in VIM, [[ and ]]

[jmagaram]

Check for existing issues

• Completed

Describe the bug / provide steps to reproduce it

I'm looking for an easy way to navigate up and down throughout my code. I thought ]] and [[ would be a good way. But it doesn't work very well. Put the cursor at the very top of this code and try ]]. Notice it skips over const areSame. This is the important bug here - whether you use const syntax or function syntax, they are both functions. I think this is related to generics but am not sure. Also notice that it jumps to the (a:number, b:number) but jumps to function in other cases. It also skips over const ZERO = 0 - maybe that is ok? I'm not sure exactly what a section is but am pretty sure the current behavior is not ok.

I'm more of a hobbyist programmer so maybe my feedback here isn't that useful. But in general I wish there was a more reliable way to move around using the syntax tree or that someone thinks this through a bit. For example, maybe a "move up/down one sibling" which moves up to the statement above, and if there is no statement above, it either jumps to the higher level function definition or stops. A "move inside/outside" that moves to the higher/lower level of the syntax tree. Ctrl+D and Ctrl+U use jumpy rather than smooth scrolling, which is disorienting. This [[ is unreliable. And { and } depend on spaces between blocks of code, which isn't reliable either.

function add(a: number, b: number) {
  return a + b;
}

const multiply = (a: number, b: number) => a * b;

const ZERO = 0;

type AreSame<T> = (a: T, b: T) => boolean;

export const areSame: AreSame<number> = (a, b) => a === b;

function subtract(a: number, b: number) {
  return a + b;
}

Zed Version and System Specs

Zed: v0.165.4 (Zed)
OS: macOS 15.2.0
Memory: 16 GiB
Architecture: aarch64

If applicable, add screenshots or screencasts of the incorrect state / behavior

No response

If applicable, attach your Zed.log file to this issue.

Zed.log

[ConradIrwin]

@jmagaram In short I agree with everything you say, and also don't know how to fix it :D.

Currently we match only some declaration forms (because it's weird if they accidentally match inside a function instead of at the top level). https://github.com/zed-industries/zed/blob/main/crates/languages/src/typescript/textobjects.scm is the config. We could possibly also add const X = () => {} matching to this list.

The Vim version of this (based on more Java-esque languages) is that typically code is organized into sections that are indented and surrounded by {}; in non-Java languages there's an impedance mismatch to overcome.

I'd be curious if the behavior of nvim-tree-sitter-textobjects more closely matches what you want? If so we can try and reduce the differences.

Otherwise I like the idea of "go to tree-sitter sibling" but the devil is in the details. The challenge is that your cursor is typically on an unexpectedly small tree-sitter node (e.g. the "const" in the function definition). Maybe we could have:

* TreeSitterNext - navigates just to the next sibling of the current node
* TreeSitterNextLine - navigates up the tree until the current node's next node starts on a different line, and then goes to that
* TreeSitterPrev
* TreeSitterPrevLine