From: Juri Linkov <juri@linkov.net>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: Mickey Petersen <mickey@masteringemacs.org>,
Yuan Fu <casouri@gmail.com>,
Theodor Thornhill <theo@thornhill.no>,
Eli Zaretskii <eliz@gnu.org>,
73404@debbugs.gnu.org
Subject: bug#73404: 30.0.50; [forward/kill/etc]-sexp commands do not behave as expected in tree-sitter modes
Date: Fri, 27 Dec 2024 09:54:11 +0200 [thread overview]
Message-ID: <87h66pr1qc.fsf@mail.linkov.net> (raw)
In-Reply-To: <jwvwmfnd0u3.fsf-monnier+emacs@gnu.org> (Stefan Monnier's message of "Wed, 25 Dec 2024 14:29:19 -0500")
[-- Attachment #1: Type: text/plain, Size: 2710 bytes --]
>>> Gentle reminder that `forward-sexp` is not a "list-navigation" function.
>>> That would be `forward-list`. We very often use sexp commands and
>>> functions to manipulate non-lists such as identifiers.
>> Do you think it would be better to override low-level functions 'scan-lists'
>> and 'scan-sexps' with new variables like 'scan-lists-function'
>> and 'scan-sexps-function', instead of adding more variables for
>> overriding top-level commands such as a new variable 'forward-list-function'
>> and 'down-list-function', like the existing 'forward-sexp-function'?
>
> Don't know.
I tried to override `scan-lists` and `scan-sexps` with advices
(a proof of concept attached below), and it works nicely.
For example, `C-M-d` moves down to the HTML element in html-ts-mode.
But then I realized there are not too many places where such
overriding might be useful. In fact, there is only 1 place
in `show-paren--default` that uses `scan-sexps`. But even this
occurrence can't be used, so I created `treesit-show-paren-data`
for `show-paren-data-function` in bug#75122.
And overriding `scan-lists` is useful only in `forward-list`,
`down-list` and `up-list`. That's all. So clearly instead
of overriding `scan-lists` and `scan-sexps`, better would be
to add 3 new variables: `forward-list-function`,
`down-list-function` and `up-list-function`.
This gives the users more flexibility to choose for example navigation
for C-M-f with a limited number of treesit lists + syntax symbols, and
for C-M-n everything that is a list in treesit. This means that with
start_atimer (-!-enum atimer_type type, struct timespec timestamp)
C-M-f could skip only the next symbol and move to
start_atimer (enum-!- atimer_type type, struct timespec timestamp)
while C-M-n could skip the whole next `parameter_declaration`
start_atimer (enum atimer_type type-!-, struct timespec timestamp)
or vice versa depending on the values of all new options `...-function`
in ts-modes.
> What I do know is that in general we'd also want an `up-sexp` operation.
> Currently we have an ugly kludge in `up-list` to try and use
> `forward-sexp-function` (which is ugly both because
> `forward-sexp-function` doesn't really provide the functionality we
> need, and because it mixes up sexp and list navigation), and it would be
> good to clean it up.
Agreed, this distinction is required for treesit. Hopefully,
this can be achieved by separating `forward-sexp-function`
and `up-list-function` that in ts-modes could be set to new
functions either `treesit-up-list` or `treesit-up-sexp`.
PS: will try to refactor everything in this attachment to new
`forward-list-function`, `down-list-function` and `up-list-function`:
[-- Attachment #2: scan-lists-advice.el --]
[-- Type: application/emacs-lisp, Size: 1594 bytes --]
prev parent reply other threads:[~2024-12-27 7:54 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-21 5:06 bug#73404: 30.0.50; [forward/kill/etc]-sexp commands do not behave as expected in tree-sitter modes Mickey Petersen
2024-09-26 7:42 ` Yuan Fu
2024-09-26 9:56 ` Mickey Petersen
2024-09-26 10:53 ` Eli Zaretskii
2024-09-26 12:13 ` Mickey Petersen
2024-09-26 13:46 ` Eli Zaretskii
2024-09-26 15:21 ` Mickey Petersen
2024-09-26 15:45 ` Eli Zaretskii
2024-09-27 5:43 ` Yuan Fu
2024-09-29 16:56 ` Juri Linkov
2024-10-01 3:57 ` Yuan Fu
2024-10-01 17:49 ` Juri Linkov
2024-10-02 6:14 ` Yuan Fu
2024-12-05 18:52 ` Juri Linkov
2024-12-05 19:53 ` Juri Linkov
2024-12-10 17:20 ` Juri Linkov
2024-12-11 6:31 ` Yuan Fu
2024-12-11 15:12 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-12-11 15:29 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-12-11 16:50 ` Mickey Petersen
2024-12-11 18:27 ` Yuan Fu
2024-12-12 7:17 ` Juri Linkov
2024-12-12 7:40 ` Eli Zaretskii
2024-12-12 7:58 ` Juri Linkov
2024-12-12 8:14 ` Juri Linkov
2024-12-12 16:31 ` Juri Linkov
2024-12-12 17:49 ` Juri Linkov
2024-12-12 19:13 ` Eli Zaretskii
2024-12-13 7:06 ` Juri Linkov
2024-12-14 11:02 ` Eli Zaretskii
2024-12-14 18:14 ` Juri Linkov
2024-12-18 7:37 ` Juri Linkov
2024-12-19 4:04 ` Yuan Fu
2024-12-19 7:14 ` Juri Linkov
2024-12-19 7:18 ` bug#74963: Ambiguous treesit named and anonymous nodes in ruby-ts-mode Juri Linkov
2024-12-24 3:02 ` Yuan Fu
2024-12-24 7:17 ` Juri Linkov
2024-12-24 7:41 ` Juri Linkov
2024-12-25 3:25 ` Dmitry Gutov
2024-12-25 7:52 ` Juri Linkov
2024-12-26 1:00 ` Dmitry Gutov
2024-12-27 7:42 ` Juri Linkov
2024-12-24 17:52 ` Juri Linkov
2024-12-24 21:03 ` Yuan Fu
2024-12-25 7:49 ` Juri Linkov
2024-12-25 9:11 ` Yuan Fu
2024-12-25 17:39 ` Juri Linkov
2024-12-19 7:34 ` bug#73404: 30.0.50; [forward/kill/etc]-sexp commands do not behave as expected in tree-sitter modes Juri Linkov
2024-12-24 19:05 ` Juri Linkov
2024-12-24 21:14 ` Yuan Fu
2024-12-25 7:44 ` Juri Linkov
2024-12-25 8:34 ` Yuan Fu
2024-12-25 17:36 ` Juri Linkov
2024-12-27 7:59 ` Juri Linkov
2024-12-25 17:19 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-12-25 18:01 ` Juri Linkov
2024-12-25 19:29 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-12-27 7:54 ` Juri Linkov [this message]
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=87h66pr1qc.fsf@mail.linkov.net \
--to=juri@linkov.net \
--cc=73404@debbugs.gnu.org \
--cc=casouri@gmail.com \
--cc=eliz@gnu.org \
--cc=mickey@masteringemacs.org \
--cc=monnier@iro.umontreal.ca \
--cc=theo@thornhill.no \
/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.