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

Previous Next

Full log

View this message in rfc822 format

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

Mattias Engdegård [2023-07-12 16:46 +0200] wrote:

> But it looks very much like S-expressions and that's the problem. If the syntax
> had been less Lisp-like then we would have been able to choose our own
> S-expressions freely and all would be well, but now it's a bit too close so that
> it's really tempting to use something with almost identical printed
> appearance. I think you have done a fine job under the circumstances.

Agreed.

>> 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.
>
> It probably isn't much of a problem in practice. I just thought that it would be
> a pity to forego the opportunity to deal with it from the start, but I
> definitely won't complain if you keep it the way it is.

And agreed.  I wouldn't be too confident straying far from the familiar
upstream syntax either.

FWIW, another result of the @-prefix capture syntax in the case of font
lock is that it is a bit harder to detect invalid capture names, such as
function names that are no longer defined:

  :feature 'foo
  :language 'bar
  '((foo @my-baz))

Where my-baz may or may not be defined as a function, and if not is
silently ignored.

There's probably more than one way to warn about such cases in
treesit.el (or catch them with testing), but my current downstream
workaround is:

  (defun my--@ (name) (intern (concat "@" (symbol-name name))))

  (defvar my--font-lock-rules
    (let ((baz (my--@ #'my-baz)))
      `( :feature foo
         :language bar
         ((foo ,baz)))))

Sadly I couldn't find a convenient compile-time way of achieving the
same (the byte-compiler doesn't see the arguments to inline functions,
and my-baz isn't known to be defined at macroexpansion time).

-- 
Basil

Previous Next

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