GNU bug report logs - #46052
Colons fooling GNUmakefile mode

Previous Next

Package: emacs;

Reported by: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>

Date: Sat, 23 Jan 2021 12:01:02 UTC

Severity: normal

Tags: confirmed, patch

Merged with 17400, 33681, 33900, 35299, 36245, 37934, 45037, 46221, 48052, 76759

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

From: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
To: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
Cc: 46052 <at> debbugs.gnu.org
Subject: bug#46052: Colons fooling GNUmakefile mode
Date: Sat, 23 Jan 2021 14:48:22 +0100
積丹尼 Dan Jacobson <jidanni <at> jidanni.org> writes:

> Perhaps already fixed.

AFAICT this is still reproducible in master (c83590b).

Out of curiosity, I took a look at make-mode.el, thinking it might just
be a matter of adding a [^\t] in a regexp somewhere after a ^ anchor,
but I'm not used to debugging font-lock setups and I don't really know
which occurrence of makefile-targets is responsible for this spurious
fontification (maybe the one paired with makefile-match-dependency,
which relies on makefile-dependency-regex?).

It sure would be nice if make-mode could check whether a line starts
with a tab before slapping the makefile-targets face on it.

(Supporting .RECIPEPREFIX would also be neat I guess, though the fact
that this variable can be set multiple times in a single makefile will
probably pose an interesting challenge.)




This bug report was last modified 73 days ago.

Previous Next


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