> On Feb 2, 2024, at 4:57 PM, João Távora wrote: > > On Sat, Feb 3, 2024 at 12:42 AM João Távora wrote: > > > > This doesn't seem to break tests, assuming it's not in these 3 there > > > were skipped because I don't have the grammar installed. > > > > Despite that, I think it's still wrong :-/ Now it moves too much, > > i.e. it never stops moving. > > This looks more promising. Works well in my tests. > > diff --git a/lisp/treesit.el b/lisp/treesit.el > index c6b9d8ff4bc..cad7497fb74 100644 > --- a/lisp/treesit.el > +++ b/lisp/treesit.el > @@ -2579,9 +2579,12 @@ treesit--navigate-thing > (setq parent (treesit-node-top-level parent thing t) > prev nil > next nil)) > - ;; If TACTIC is `restricted', the implementation is very simple. > + ;; If TACTIC is `restricted', the implementation is reasonably simple. > (if (eq tactic 'restricted) > - (setq pos (funcall advance (if (> arg 0) next prev))) > + (setq pos (funcall advance (cond ((and (null next) (null prev)) > + parent) > + ((> arg 0) next) > + (t prev)))) > ;; For `nested', it's a bit more work: > ;; Move... > (if (> arg 0) Thanks for looking into this, Joao. IME a very useful characteristic of forward-sexp is that it stays in the same “level” and doesn’t go up automatically when there’s no siblings (when there’s a closing delimiter). Eg, in an Elisp buffer, forward-sexp stops at the closing parenthesis, in C, it should stop at the closing bracket. Also you don’t want to check for prev when moving forward, and vice versa, ie, we don’t want to check (null next) and (null prev) together. So, how do you like this patch: Yuan