GNU bug report logs - #44418
28.0.50; Spliced variable not matched as symbol in isearch

Previous Next

Full log

Message #68 received at 44418 <at> debbugs.gnu.org (full text, mbox):

From: Yuan Fu <casouri <at> gmail.com>
To: Mattias Engdegård <mattias.engdegard <at> gmail.com>
Cc: Basil Contovounesios <contovob <at> tcd.ie>, 44418 <at> debbugs.gnu.org,
 Lars Ingebrigtsen <larsi <at> gnus.org>, monnier <at> iro.umontreal.ca
Subject: Re: bug#44418: 28.0.50; Spliced variable not matched as symbol in
 isearch
Date: Sat, 8 Jul 2023 16:48:57 -0700

> On Jun 24, 2023, at 3:12 AM, Mattias Engdegård <mattias.engdegard <at> gmail.com> wrote:
> 
> 24 juni 2023 kl. 00.39 skrev Yuan Fu <casouri <at> 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.

Sorry for taking so long, I never decided against other people for important things in Emacs, and I certainly don’t want to make a wrong decision and regret it later, so I struggled a bit and kept procrastinating 😃

I agree that it’s easy to figure out what does the detached @ syntax mean. I mainly just don’t like having two ways to do the same thing.

Since I don’t use search symbol myself, I can’t grasp the importance of it. You apparently care about it enough to go this far, and I’m willing to take your word for it.

You mentioned sexp queries, which reminded me that using the detached syntax would allow people to interpolate capture names with quasi quotes. That’s a plus for the detached syntax.

Ultimately I’m still on the fence for this. But if you still want to add it, please go ahead :-)

Yuan

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.