GNU bug report logs -
#44418
28.0.50; Spliced variable not matched as symbol in isearch
Previous Next
Reported by: "Basil L. Contovounesios" <contovob <at> tcd.ie>
Date: Tue, 3 Nov 2020 15:39:01 UTC
Severity: minor
Merged with 22238
Found in versions 25.0.50, 28.0.50
Done: Mattias Engdegård <mattias.engdegard <at> gmail.com>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 44418 in the body.
You can then email your comments to 44418 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#44418
; Package
emacs
.
(Tue, 03 Nov 2020 15:39:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
"Basil L. Contovounesios" <contovob <at> tcd.ie>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Tue, 03 Nov 2020 15:39:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Severity: minor
0. emacs -Q
1. (let (x) `(,@x))
2. M-s _ x
This highlights the bound x, but not the spliced x. The same happens
with 'M-s .' or the equivalent 'C-M-s'.
This is because lisp--mode-syntax-table gives 'prefix' syntax to ?, and
'symbol' syntax to ?@. Is it possible to give 'prefix' syntax to ",@"
as a whole, and in general?
[This behaviour exists since at least as far back as Emacs 24.5.1.
I wouldn't be surprised if this has been reported before,
but my searches came up dry.]
Thanks,
--
Basil
In GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo version 1.16.0, Xaw3d scroll bars)
of 2020-11-02 built on thunk
Repository revision: 95f7a2835a79c1f12b5dc86230405e8040910c72
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12008000
System Description: Debian GNU/Linux bullseye/sid
Configured using:
'configure 'CC=ccache gcc' 'CFLAGS=-O2 -march=native' --config-cache
--prefix=/home/blc/.local --with-x-toolkit=lucid
--with-file-notification=yes --with-x'
Configured features:
XAW3D XPM JPEG TIFF GIF PNG RSVG CAIRO SOUND GPM DBUS GSETTINGS GLIB
NOTIFY INOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE HARFBUZZ M17N_FLT
LIBOTF ZLIB TOOLKIT_SCROLL_BARS LUCID X11 XDBE XIM MODULES THREADS
LIBSYSTEMD JSON PDUMPER LCMS2
Important settings:
value of $LANG: en_IE.UTF-8
value of $XMODIFIERS: @im=ibus
locale-coding-system: utf-8-unix
Major mode: Lisp Interaction
Minor modes in effect:
tooltip-mode: t
global-eldoc-mode: t
eldoc-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
line-number-mode: t
transient-mark-mode: t
Load-path shadows:
None found.
Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
rfc822 mml easymenu mml-sec epa derived epg epg-config gnus-util rmail
rmail-loaddefs auth-source cl-seq eieio eieio-core cl-macs
eieio-loaddefs password-cache json map text-property-search time-date
subr-x seq byte-opt gv bytecomp byte-compile cconv mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader cl-loaddefs
cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils
misearch multi-isearch tooltip eldoc electric uniquify ediff-hook
vc-hooks lisp-float-type mwheel term/x-win x-win term/common-win x-dnd
tool-bar dnd fontset image regexp-opt fringe tabulated-list replace
newcomment text-mode elisp-mode lisp-mode prog-mode register page
tab-bar menu-bar rfn-eshadow isearch timer select scroll-bar mouse
jit-lock font-lock syntax facemenu font-core term/tty-colors frame
minibuffer cl-generic cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
composite charscript charprop case-table epa-hook jka-cmpr-hook help
simple abbrev obarray cl-preloaded nadvice button loaddefs faces
cus-face macroexp files window text-properties overlay sha1 md5 base64
format env code-pages mule custom widget hashtable-print-readable
backquote threads dbusbind inotify lcms2 dynamic-setting
system-font-setting font-render-setting cairo x-toolkit x multi-tty
make-network-process emacs)
Memory information:
((conses 16 52709 5287)
(symbols 48 6786 1)
(strings 32 19027 1309)
(string-bytes 1 616874)
(vectors 16 12242)
(vector-slots 8 168612 9829)
(floats 8 23 45)
(intervals 56 231 0)
(buffers 992 10))
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#44418
; Package
emacs
.
(Tue, 07 Jun 2022 10:31:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 44418 <at> debbugs.gnu.org (full text, mbox):
"Basil L. Contovounesios" <contovob <at> tcd.ie> writes:
> 0. emacs -Q
> 1. (let (x) `(,@x))
> 2. M-s _ x
>
> This highlights the bound x, but not the spliced x. The same happens
> with 'M-s .' or the equivalent 'C-M-s'.
>
> This is because lisp--mode-syntax-table gives 'prefix' syntax to ?, and
> 'symbol' syntax to ?@. Is it possible to give 'prefix' syntax to ",@"
> as a whole, and in general?
(This is still present in Emacs 29.)
I'm not sure whether that is possible or not -- perhaps Stefan knows;
added to the CCs.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#44418
; Package
emacs
.
(Tue, 07 Jun 2022 12:06:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 44418 <at> debbugs.gnu.org (full text, mbox):
>> 0. emacs -Q
>> 1. (let (x) `(,@x))
>> 2. M-s _ x
>>
>> This highlights the bound x, but not the spliced x. The same happens
>> with 'M-s .' or the equivalent 'C-M-s'.
>>
>> This is because lisp--mode-syntax-table gives 'prefix' syntax to ?, and
>> 'symbol' syntax to ?@. Is it possible to give 'prefix' syntax to ",@"
>> as a whole, and in general?
>
> (This is still present in Emacs 29.)
>
> I'm not sure whether that is possible or not -- perhaps Stefan knows;
> added to the CCs.
`@x` is a valid symbol, which is why `?@` is given symbol syntax.
If we want to fix the above search we need to use
`syntax-propertize-function` to change the syntax of those `@` that
follow a comma.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#44418
; Package
emacs
.
(Tue, 07 Jun 2022 17:46:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 44418 <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
> `@x` is a valid symbol, which is why `?@` is given symbol syntax.
> If we want to fix the above search we need to use
> `syntax-propertize-function` to change the syntax of those `@` that
> follow a comma.
The following seems to do the trick -- does this look OK to you?
diff --git a/lisp/progmodes/elisp-mode.el b/lisp/progmodes/elisp-mode.el
index 77bf3f1ed1..210270bc67 100644
--- a/lisp/progmodes/elisp-mode.el
+++ b/lisp/progmodes/elisp-mode.el
@@ -245,6 +245,9 @@ elisp-mode-syntax-propertize
;; Empty symbol.
("##" (0 (unless (nth 8 (syntax-ppss))
(string-to-syntax "_"))))
+ ;; Give ,@ a prefix syntax.
+ (",@" (0 (unless (ppss-comment-or-string-start (syntax-ppss))
+ (string-to-syntax "'"))))
;; Unicode character names. (The longest name is 88 characters
;; long.)
("\\?\\\\N{[-A-Za-z0-9 ]\\{,100\\}}"
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#44418
; Package
emacs
.
(Tue, 07 Jun 2022 18:21:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 44418 <at> debbugs.gnu.org (full text, mbox):
> The following seems to do the trick -- does this look OK to you?
Fine by me,
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#44418
; Package
emacs
.
(Tue, 07 Jun 2022 18:29:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 44418 <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>> The following seems to do the trick -- does this look OK to you?
>
> Fine by me,
OK; now pushed to Emacs 29.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
bug marked as fixed in version 29.1, send any further explanations to
44418 <at> debbugs.gnu.org and "Basil L. Contovounesios" <contovob <at> tcd.ie>
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Tue, 07 Jun 2022 18:29:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#44418
; Package
emacs
.
(Wed, 08 Jun 2022 12:30:02 GMT)
Full text and
rfc822 format available.
Message #25 received at 44418 <at> debbugs.gnu.org (full text, mbox):
This led to edebug tests hanging, so I've reverted the change for now
and am reopening this bug report. The offending change was
d003848b5e3ad2dfbe84cc62b99776fdc6734325.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
bug No longer marked as fixed in versions 29.1 and reopened.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Wed, 08 Jun 2022 12:30:03 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#44418
; Package
emacs
.
(Wed, 21 Jun 2023 16:00:02 GMT)
Full text and
rfc822 format available.
Message #30 received at 44418 <at> debbugs.gnu.org (full text, mbox):
A tentative fix has been pushed to master. I didn't bother with a NEWS entry but will be happy to add one if someone thinks it would be useful.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#44418
; Package
emacs
.
(Wed, 21 Jun 2023 17:16:02 GMT)
Full text and
rfc822 format available.
Message #33 received at 44418 <at> debbugs.gnu.org (full text, mbox):
> Cc: Basil Contovounesios <contovob <at> tcd.ie>, 44418 <at> debbugs.gnu.org,
> Stefan Monnier <monnier <at> iro.umontreal.ca>
> From: Mattias Engdegård <mattias.engdegard <at> gmail.com>
> Date: Wed, 21 Jun 2023 17:59:44 +0200
>
> A tentative fix has been pushed to master. I didn't bother with a NEWS entry but will be happy to add one if someone thinks it would be useful.
If this changes user-facing behavior or behavior of public functions,
I think we must call this out in NEWS, under "incompatible changes".
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#44418
; Package
emacs
.
(Thu, 22 Jun 2023 08:51:02 GMT)
Full text and
rfc822 format available.
Message #36 received at 44418 <at> debbugs.gnu.org (full text, mbox):
> If this changes user-facing behavior or behavior of public functions,
> I think we must call this out in NEWS, under "incompatible changes".
This is just a bug fix, not a change to documented or otherwise intended behaviour.
Maybe announcing it NEWS would make some people happy to know that the bug has finally been fixed.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#44418
; Package
emacs
.
(Thu, 22 Jun 2023 10:12:02 GMT)
Full text and
rfc822 format available.
Message #39 received at 44418 <at> debbugs.gnu.org (full text, mbox):
> From: Mattias Engdegård <mattias.engdegard <at> gmail.com>
> Date: Thu, 22 Jun 2023 10:50:18 +0200
> Cc: larsi <at> gnus.org,
> contovob <at> tcd.ie,
> 44418 <at> debbugs.gnu.org,
> monnier <at> iro.umontreal.ca
>
> > If this changes user-facing behavior or behavior of public functions,
> > I think we must call this out in NEWS, under "incompatible changes".
>
> This is just a bug fix, not a change to documented or otherwise intended behaviour.
Whether it was intended is not necessarily relevant. It could be
known long-standing behavior that became a de-facto standard. Which
is why I think we should call it out.
If you are unwilling to mention this in NEWS, please describe the
change and I will add to NEWS what I think needs to be added.
TIA
Reply sent
to
Mattias Engdegård <mattias.engdegard <at> gmail.com>
:
You have taken responsibility.
(Thu, 22 Jun 2023 11:26:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
"Basil L. Contovounesios" <contovob <at> tcd.ie>
:
bug acknowledged by developer.
(Thu, 22 Jun 2023 11:26:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 44418-done <at> debbugs.gnu.org (full text, mbox):
> Whether it was intended is not necessarily relevant. It could be
> known long-standing behavior that became a de-facto standard. Which
> is why I think we should call it out.
That's fine with me -- now done. Closing bug.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#44418
; Package
emacs
.
(Fri, 23 Jun 2023 11:59:02 GMT)
Full text and
rfc822 format available.
Message #47 received at 44418 <at> debbugs.gnu.org (full text, mbox):
Mattias Engdegård [2023-06-21 17:59 +0200] wrote:
> A tentative fix has been pushed to master.
Thanks. Too bad the same can't be done for tree-sitter capture names
such as @font-lock-foo-face or @my--fontify-foo :).
--
Basil
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#44418
; Package
emacs
.
(Fri, 23 Jun 2023 12:07:01 GMT)
Full text and
rfc822 format available.
Message #50 received at 44418 <at> debbugs.gnu.org (full text, mbox):
23 juni 2023 kl. 13.58 skrev Basil Contovounesios <contovob <at> tcd.ie>:
> Too bad the same can't be done for tree-sitter capture names
> such as @font-lock-foo-face or @my--fontify-foo :).
Yes, I think that's a bit unfortunate. Maybe we can introduce (@ NAME) as alternative syntax?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#44418
; Package
emacs
.
(Fri, 23 Jun 2023 16:55:02 GMT)
Full text and
rfc822 format available.
Message #53 received at 44418 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> Maybe we can introduce (@ NAME) as alternative syntax?
Here is a proof-of-concept (missing tests and documentation), but it works and I think it's a definite improvement.
Maybe we can get a blessing from Yuan Fu. To recap, this permits the syntax (@ symbol-name) as an alternative to @symbol-name in treesit queries because that allows symbol searching to match the symbol-name, and this can be really helpful.
[treesit-alt-capture-construct.diff (application/octet-stream, attachment)]
[Message part 3 (text/plain, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#44418
; Package
emacs
.
(Fri, 23 Jun 2023 22:40:02 GMT)
Full text and
rfc822 format available.
Message #56 received at 44418 <at> debbugs.gnu.org (full text, mbox):
Mattias Engdegård <mattias.engdegard <at> gmail.com> writes:
>> Maybe we can introduce (@ NAME) as alternative syntax?
>
> Here is a proof-of-concept (missing tests and documentation), but it works and I think it's a definite improvement.
>
> Maybe we can get a blessing from Yuan Fu. To recap, this permits the
> syntax (@ symbol-name) as an alternative to @symbol-name in treesit
> queries because that allows symbol searching to match the symbol-name,
> and this can be really helpful.
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.
Yuan
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#44418
; Package
emacs
.
(Sat, 24 Jun 2023 06:40:02 GMT)
Full text and
rfc822 format available.
Message #59 received at 44418 <at> debbugs.gnu.org (full text, mbox):
> Cc: contovob <at> tcd.ie, 44418 <at> debbugs.gnu.org, larsi <at> gnus.org,
> monnier <at> iro.umontreal.ca
> From: Yuan Fu <casouri <at> gmail.com>
> Date: Fri, 23 Jun 2023 15:39:20 -0700
>
>
> Mattias Engdegård <mattias.engdegard <at> gmail.com> writes:
>
> >> Maybe we can introduce (@ NAME) as alternative syntax?
> >
> > Here is a proof-of-concept (missing tests and documentation), but it works and I think it's a definite improvement.
> >
> > Maybe we can get a blessing from Yuan Fu. To recap, this permits the
> > syntax (@ symbol-name) as an alternative to @symbol-name in treesit
> > queries because that allows symbol searching to match the symbol-name,
> > and this can be really helpful.
>
> 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.
Given what Yuan says, I think we should drop this for now. Let's
collect some real-world use experience, once Emacs 29 is released,
before planning any such changes.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#44418
; Package
emacs
.
(Sat, 24 Jun 2023 10:13:01 GMT)
Full text and
rfc822 format available.
Message #62 received at 44418 <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#44418
; Package
emacs
.
(Sun, 25 Jun 2023 11:39:02 GMT)
Full text and
rfc822 format available.
Message #65 received at 44418 <at> debbugs.gnu.org (full text, mbox):
Mattias Engdegård [2023-06-24 12:12 +0200] wrote:
> 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.
FWIW, as a workaround I'm trying to use 'M-s M-.' in place of 'M-s .'.
I may eventually be compelled to customise
isearch-forward-thing-at-point with a custom 'thing' specifically for
@-prefixed Elisp symbols.
--
Basil
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#44418
; Package
emacs
.
(Sat, 08 Jul 2023 23:50:01 GMT)
Full text and
rfc822 format available.
Message #68 received at 44418 <at> debbugs.gnu.org (full text, mbox):
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#44418
; Package
emacs
.
(Sun, 09 Jul 2023 06:08:02 GMT)
Full text and
rfc822 format available.
Message #71 received at 44418 <at> debbugs.gnu.org (full text, mbox):
> Cc: Basil Contovounesios <contovob <at> tcd.ie>, 44418 <at> debbugs.gnu.org,
> Lars Ingebrigtsen <larsi <at> gnus.org>, monnier <at> iro.umontreal.ca
> From: Yuan Fu <casouri <at> gmail.com>
> Date: Sat, 8 Jul 2023 16:48:57 -0700
>
> 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 :-)
I'd like to hear Stefan's opinion on this, before we make such a
change (if we make it).
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#44418
; Package
emacs
.
(Sun, 09 Jul 2023 12:37:02 GMT)
Full text and
rfc822 format available.
Message #74 received at 44418 <at> debbugs.gnu.org (full text, mbox):
>> 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 :-)
>
> I'd like to hear Stefan's opinion on this, before we make such a
> change (if we make it).
Yuan knows this area much better than I do, and I fully trust his
judgment on this.
The only I'd point out is that if we introduce a (@ ...) syntax here
we should try and phase out the old @... syntax, i.e. emit an
obsolescence warning when we bump into such code.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#44418
; Package
emacs
.
(Wed, 12 Jul 2023 14:48:01 GMT)
Full text and
rfc822 format available.
Message #77 received at 44418 <at> debbugs.gnu.org (full text, mbox):
9 juli 2023 kl. 01.48 skrev Yuan Fu <casouri <at> gmail.com>:
> 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
No, I'm the one to apologise here: in no way did I intend to heap pressure on you.
The native tree-sitter query syntax is actually not using S-expressions at all -- the parsing is completely ad-hoc, and the query data is constructed directly during parsing.
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.
> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#44418
; Package
emacs
.
(Wed, 12 Jul 2023 15:10:01 GMT)
Full text and
rfc822 format available.
Message #80 received at 44418 <at> debbugs.gnu.org (full text, mbox):
On 09/07/2023 15:36, Stefan Monnier via Bug reports for GNU Emacs, the
Swiss army knife of text editors wrote:
> The only I'd point out is that if we introduce a (@ ...) syntax here
> we should try and phase out the old @... syntax, i.e. emit an
> obsolescence warning when we bump into such code.
IMO that's indeed the biggest problem with the proposal: if we could
swap @ in the current syntax for something else, that might be ideal.
But as proposed (and at this stage of Emacs 29 development) we'll likely
carry two different syntaxes for a number of years, and only one of them
will show up in symbol searches (such as xref-find-references or isearch
for "\\_<foo"). Having these methods work in some cases can discourage
the users from trying other methods, or simply searching for input
prefixed with "@".
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#44418
; Package
emacs
.
(Wed, 12 Jul 2023 15:28:01 GMT)
Full text and
rfc822 format available.
Message #83 received at 44418 <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#44418
; Package
emacs
.
(Tue, 18 Jul 2023 01:55:02 GMT)
Full text and
rfc822 format available.
Message #86 received at 44418 <at> debbugs.gnu.org (full text, mbox):
On 12/07/2023 18:26, Basil Contovounesios via Bug reports for GNU Emacs,
the Swiss army knife of text editors wrote:
> Where my-baz may or may not be defined as a function, and if not is
> silently ignored.
@captures can also be face names directly, not always functions.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#44418
; Package
emacs
.
(Tue, 18 Jul 2023 08:36:01 GMT)
Full text and
rfc822 format available.
Message #89 received at 44418 <at> debbugs.gnu.org (full text, mbox):
Dmitry Gutov [2023-07-18 04:54 +0300] wrote:
> On 12/07/2023 18:26, Basil Contovounesios via Bug reports for GNU Emacs, the
> Swiss army knife of text editors wrote:
>> Where my-baz may or may not be defined as a function, and if not is
>> silently ignored.
>
> @captures can also be face names directly, not always functions.
Of course, that's why I said:
> it is a bit harder to detect invalid capture names, such as
^^^^^^^
> function names that are no longer defined
--
Basil
Merged 22238 44418.
Request was from
"Basil L. Contovounesios" <contovob <at> tcd.ie>
to
control <at> debbugs.gnu.org
.
(Fri, 28 Jul 2023 08:06:02 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Sat, 26 Aug 2023 11:24:06 GMT)
Full text and
rfc822 format available.
This bug report was last modified 1 year and 281 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.