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

[Basil Contovounesios]

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