bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#74307: 30.0.92; emacs-lisp font-locking word regexp


From: Eli Zaretskii
Subject: bug#74307: 30.0.92; emacs-lisp font-locking word regexp
Date: Thu, 05 Dec 2024 09:38:48 +0200

> From: Juri Linkov <juri@linkov.net>
> Cc: Roland Winkler <winkler@gnu.org>,  Stefan Monnier
>  <monnier@iro.umontreal.ca>,  74307@debbugs.gnu.org
> Date: Thu, 05 Dec 2024 09:20:16 +0200
> 
> >>   (setq foo "\\<foo\\>")
> >> 
> >> The part "foo\\" of the string "\\<foo\\>" will get
> >> font-lock-variable-name-face, which looks odd.
> >> 
> >> I believe, this is due to a clause in lisp-mode.el that says
> >> 
> >>          ;; Words inside \\[], \\<>, \\{} or \\`' tend to be for
> >>          ;; `substitute-command-keys'.
> >> 
> >> But this assumption is not always correct, in particular if ">" is
> >> preceded by "\\", which happens when constructing regexps.
> >
> > I believe you are saying that in
> >
> >          (,(rx "\\\\" (or (seq "<" (group-n 1 lisp-mode-symbol) ">")
> >                           (seq "{" (group-n 1 lisp-mode-symbol) "}")))
> >           (1 font-lock-variable-name-face prepend))
> >
> > we should use something like the below instead?
> >
> >      (,(rx "\\\\" (or (seq "<" (group-n 1 lisp-mode-symbol) (not "\\\\") 
> > ">")
> >                       (seq "{" (group-n 1 lisp-mode-symbol) (not "\\\\") 
> > "}"))
> 
> The problem is that this removes highlighting from the last character
> because it doesn't get into the group:
> 
>   (rx (seq "[" (group-n 1 lisp-mode-symbol) (not "\\") "]"))
>   => "\\[\\(?1:\\(?:\\w\\|\\s_\\|\\\\.\\)+\\)[^\\]]"
> 
> A possible solution is to move (not "\\") inside the group:
> 
>   (rx (seq "[" (group-n 1 (seq lisp-mode-symbol (not "\\"))) "]"))
>   => "\\[\\(?1:\\(?:\\w\\|\\s_\\|\\\\.\\)+[^\\]\\)]"
> 
> But this removes highlighting completely from the reported case of
> (setq foo "\\<foo\\>").  However, I guess it should not have highlighting
> anyway because this is an incorrect syntax of `substitute-command-keys'
> that should match only \\[], \\<>, \\{} or \\`' without the second \\

Sorry, I don't understand: the change which was supposed to fix this
was already installed.  If you are saying it caused regressions, could
you please show a recipe for reproducing those regressions?





reply via email to

[Prev in Thread] Current Thread [Next in Thread]