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

[Mattias Engdegård]

24 juni 2023 kl. 00.39 skrev Yuan Fu <casouri@gmail.com>:

> 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.