GNU bug report logs - #9407
GNUmakefile mode thinks comments need a space before them after colon

Previous Next

To reply to this bug, email your comments to 9407 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: jidanni <at> jidanni.org
To: bug-gnu-emacs <at> gnu.org
Subject: GNUmakefile mode thinks comments need a space before them after colon
Date: Tue, 30 Aug 2011 18:32:31 +0800

$ cat makefile
m: #this is a comment, which we note is in proper comment color
n:#this is also a comment, which we note is NOT in proper comment color
$ emacs -Q makefile

Message #12 received at 9407 <at> debbugs.gnu.org (full text, mbox):

From: Matt Armstrong <gmatta <at> gmail.com>
To: 9407 <at> debbugs.gnu.org
Subject: GNUmakefile mode thinks comments need a space before them after colon
Date: Sat, 6 Feb 2021 14:50:54 -0800

I looked at this bug a bit over the past few days and found it to be a
surprisingly subtle bug. So subtle, in fact, that I am inclined to
give up trying to fix it, at least without removing make-mode.el
features. I'll explain why.

Despite bug#9407 being the main bug, some interesting discussion
happened in bug#33247, as well as in some of the other bugs filed by
Dan Jacobson for similar issues.

In bug#9407 Stefan said that make-mode.el aims to fontify shell
comments in make commands, which is why the mode copied some of the
shell mode regex code to recognize them.

In the same bug, Alan suggested adding the colon `:' to
`makefile-syntax-propertize-function' in make-mode.el to fix this bug.

First, Alan's suggested fix is insufficient, because it trades one
problem for another. In the example below, it will correctly highlight
the first comment below, but it will also highlight "not a comment" as
a comment, when in fact it isn't.

target:#This is a comment
        echo This is:#not a comment

In other words, today Emacs highlights comments only if they're valid
Bourne shell comments, despite only the command lines being written in
shell. This heuristic seems to be correct for almost everything in a
Makefile, but edge cases like this bug arise.

Two things send me running for the hills and giving up:

 - GNU make lets you change the shell used for commands. It need not
be a Bourne shell at all. It could be as exotic as Scheme shell! Yet
make-mode.el attempts to highlight a rule's commands as if they were
shell code (there is logic in there to support perl as well).
 - GNU make lets you change the leading character used for command
lines, so it need not even be a TAB character.

The first point is the biggie. Given that the command language, at
least in a GNU makefile, is not fixed, I might opt to strip out all
highlighting of the underlying command language, and instead focus on
parsing command text in the limited way that make itself does, and
highlight the rest as, perhaps, a string. This might fix a number of
separate issues as reported by Dan, some of which seem to relate to
this. Just a thought.

Previous Next

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