Subject: Re: bug#44418: 28.0.50; Spliced variable not matched as symbol in isearch

From: Mattias Engdegård <[email-masked]>
Date: Sat, 24 Jun 2023 12:12:44 +0200

24 juni 2023 kl. 00.39 skrev Yuan Fu <[email-masked]>:

> I want to point out that a) this will add complexity and make the syntax
> harder to read and learn (however minuscule the impact might be); b) is
> not enough by itself to make isearch symbol work with capture names:
> whoever write the code must _use_ this syntax; and c) I don’t think
> isearch symbol itself is popular/important enough to justify the change.

Well, you are the treesit maintainer and get to decide, but perhaps I could try to sway your opinion. First note that the change is very small with no increase in complexity -- most treesit users would never bother to learn that there is an alternative @SYMBOL notation in addition to the standard (@ SYMBOL).

Furthermore, the @SYMBOL notation is quite un-Lisp-like and alien to Lisp programmers who definitely tend to make use of symbol search, which is why this bug (about the ,@ prefix) was so annoying: it not only prevented us from effectively finding all occurrences of a symbol, but deprived us of a common way to check that the spelling of name is correct and corresponds to its definition. A pity if we now introduce the same kind of bug again, unforced.

I did a quick translation of some treesit patterns in various language modes from @SYMBOL to (@ SYMBOL) and the result was no less readable. Try it yourself.

Your decision to expose treesit queries as Elisp S-expressions was fortunate, as can be seen by the fact that no Emacs editing mode seems to use the other (string) syntax, and the modes make frequent use of backquote forms to interpolate Lisp values into patterns.