GNU bug report logs -
#76759
[PATCH] 31.0.50; makefile-mode: incorrectly highlights make-instructions as make targets
Previous Next
Reported by: Jostein Kjønigsen <jostein <at> secure.kjonigsen.net>
Date: Wed, 5 Mar 2025 09:34:02 UTC
Severity: normal
Tags: confirmed, patch
Merged with 17400,
33681,
33900,
35299,
36245,
37934,
45037,
46052,
46221,
48052
Found in version 26.1
Done: Stefan Monnier <monnier <at> iro.umontreal.ca>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
Your message dated Sun, 09 Mar 2025 22:08:04 -0400
with message-id <jwv1pv5psg4.fsf-monnier+emacs <at> gnu.org>
and subject line Re: bug#76759: [PATCH] 31.0.50; makefile-mode: incorrectly highlights make-instructions as make targets
has caused the debbugs.gnu.org bug report #76759,
regarding GNUmakefile mode thinks : in shell commands starts targets
to be marked as done.
(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)
--
76759: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=76759
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
Can you believe "echo a ||" is shown in face (makefile-targets)
$ cat Makefile
x:
echo a || :
echo b
in GNUmakefile mode defined in ‘make-mode.el’.
emacs-version "25.2.2"
[Message part 3 (message/rfc822, inline)]
> Any news on this one?
Looks OK, tho I think it's a bit more strict than necessary: the TABs we
need to avoid can be only at the beginning of the line, so not inside
the $(...).
So it's only one of the [^...] that needs the \t.
Here's what I did:
- Start from the current monster:
"^\\(\\(?:\\$\\(?:[({]\\(?:\\$\\(?:[({]\\(?:\\$\\(?:[^({]\\|.[^\n$#})]+?[})]\\)\\|[^\n$#)}]\\)+?[})]\\|[^({]\\)\\|[^\n$#)}]\\)+?[})]\\|[^({]\\)\\|[^\n$#:=]\\)+?\\)\\(:\\)\\(?:[ \t]*$\\|[^=\n]\\(?:[^#\n]*?;[ \t]*\\(.+\\)\\)?\\)"
- Change the `\\(?:[^({]\\|.` to `\\(?:[^({]\\|[({]` because I think
the `.` was just an optimization. And since the two alternatives are
now mutually exclusive, swap them:
\\(?:[^({]\\|.[^\n$#})]+?[})]\\)
=>
\\(?:[({][^\n$#})]+?[})]\\|[^({]\\)
- Now the regexp has become:
"^\\(\\(?:\\$\\(?:[({]\\(?:\\$\\(?:[({]\\(?:\\$\\(?:[({][^\n$#})]+?[})]\\|[^({]\\)\\|[^\n$#)}]\\)+?[})]\\|[^({]\\)\\|[^\n$#)}]\\)+?[})]\\|[^({]\\)\\|[^\n$#:=]\\)+?\\)\\(:\\)\\(?:[ \t]*$\\|[^=\n]\\(?:[^#\n]*?;[ \t]*\\(.+\\)\\)?\\)"
- Make the nested construction explicit, so it's a bit more manageable:
(letrec ((elems-re
(lambda (n &optional outer)
(if (< n 1)
"[^\n$#})]+?"
(concat "\\(?:\\$\\(?:"
"[({]" (funcall elems-re (- n 1)) "[})]"
"\\|[^({]\\)"
"\\|[^\n$#" (if outer ":=" ")}") "]\\)+?")))))
(concat
;; Allow for two nested levels $(v1:$(v2:$(v3:a=b)=c)=d)
"^\\(" (funcall elems-re 3 'outer)
"\\)\\(:\\)\\(?:[ \t]*$\\|[^=\n]\\(?:[^#\n]*?;[ \t]*\\(.+\\)\\)?\\)"))
- Disallow TABs in the outer case by replacing ":=" with "\t:=" (that's
one of the TABs you added in your version of the patch).
This is still not quite right, since AFAIK TABs are allowed to appear
outside of $(...) as long as they're not at BOL, but I think it's better
than what we've had so far (and the regexp still has several other
limitations anyway).
Pushed to `master`.
Stefan
This bug report was last modified 72 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.