bug#9407: GNUmakefile mode thinks comments need a space before them after colon

[Matt Armstrong <gmatta@gmail.com>]

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.