From: "João Távora" <joaotavora@gmail.com>
To: Yuan Fu <casouri@gmail.com>
Cc: 68899@debbugs.gnu.org
Subject: bug#68899: Treesitter's forward-sexp-function
Date: Sun, 4 Feb 2024 12:40:33 +0000 [thread overview]
Message-ID: <CALDnm51ndjVhmAFDi77e3nxPDeAiKiUok5v-n1GU4RPgYm0X2g@mail.gmail.com> (raw)
In-Reply-To: <981BC2F8-9B7F-40AC-9C1A-C995A71F5C97@gmail.com>
On Sun, Feb 4, 2024 at 5:35 AM Yuan Fu <casouri@gmail.com> wrote:
> 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.
I agree. There are other useful characteristics, but this is one of them.
It allows be to mark regions of text up to points that I'm not even seeing.
> 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.
I get it. I used those existing results as a proxy to know if we're
in the middle
of a leaf. I _think_ it's sound (maybe I'm wrong).
> So, how do you like this patch:
It works fine, but as far as I can tell does exactly the same as mine, and
looks to be slightly more difficult to read and uses a further treesit
query to check if this is a leaf node. But it's absolutley fine really.
One way my patch can be described in plain english is
"if we're not at an inter-thing boundary, we navigate to such boundary"
And then the meaning of checking prev _and_ next becomes obvious
and it isn't necessary to perform the additional check that we're in a
leaf node.
So go ahead and push whichever patch you prefer, and thanks.
João
next prev parent reply other threads:[~2024-02-04 12:40 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-02 21:47 bug#68899: Treesitter's forward-sexp-function João Távora
2024-02-03 0:42 ` João Távora
2024-02-03 0:57 ` João Távora
2024-02-04 5:35 ` Yuan Fu
2024-02-04 12:40 ` João Távora [this message]
2024-02-05 0:50 ` Yuan Fu
2024-02-05 1:08 ` João Távora
2024-02-06 7:25 ` Yuan Fu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CALDnm51ndjVhmAFDi77e3nxPDeAiKiUok5v-n1GU4RPgYm0X2g@mail.gmail.com \
--to=joaotavora@gmail.com \
--cc=68899@debbugs.gnu.org \
--cc=casouri@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.