bug#46052: Colons fooling GNUmakefile mode

bug#46052: Colons fooling GNUmakefile mode

[積丹尼 Dan Jacobson]

Colons on lines 2 and 4 shouldn't change the line color:
$ cat Makefile
eee:
	set -x; $c 11999 3555; $c 11999 3355; :
	set -x; $c 9999   999; $c 9999   799;
	set -x; $c 8499  1606; $c 8499   599; :

emacs-version "27.1".
Perhaps already fixed.

bug#46052: Colons fooling GNUmakefile mode

[Kévin Le Gouguec]

積丹尼 Dan Jacobson <jidanni@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.)

bug#46052: Colons fooling GNUmakefile mode

[Eli Zaretskii]

> From: Kévin Le Gouguec <kevin.legouguec@gmail.com>
> Date: Sat, 23 Jan 2021 14:48:22 +0100
> Cc: 46052@debbugs.gnu.org
> 
> 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.

I'm not sure a target line cannot possibly start with a TAB.

bug#46052: Colons fooling GNUmakefile mode

[Kévin Le Gouguec]

Eli Zaretskii <eliz@gnu.org> writes:

> I'm not sure a target line cannot possibly start with a TAB.

I'll admit to not being an expert in makefile syntax; I do find this
entry in (info "(make) Error Messages") encouraging though:

> 'recipe commences before first target. Stop.'
> 'missing rule before recipe. Stop.'
>      This means the first thing in the makefile seems to be part of a
>      recipe: it begins with a recipe prefix character and doesn't appear
>      to be a legal 'make' directive (such as a variable assignment).
>      Recipes must always be associated with a target.

While that phrasing doesn't rule out subsequent targets from starting
with a TAB, empirically that seems to be the case:

#+begin_src makefile
foo:
	echo foo

	bar:
	echo bar
#+end_src

$ make
echo foo
foo
bar:
make: bar:: No such file or directory
make: *** [makefile:3: foo] Error 127

#+begin_src makefile
foo:
	echo foo

QUUX = CORGE

	bar:
	echo bar
#+end_src

$ make
makefile:6: *** recipe commences before first target.  Stop.

bug#46052: Colons fooling GNUmakefile mode

[Eli Zaretskii]

> From: Kévin Le Gouguec <kevin.legouguec@gmail.com>
> Cc: jidanni@jidanni.org,  46052@debbugs.gnu.org
> Date: Sat, 23 Jan 2021 15:58:58 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I'm not sure a target line cannot possibly start with a TAB.
> 
> I'll admit to not being an expert in makefile syntax; I do find this
> entry in (info "(make) Error Messages") encouraging though:
> 
> > 'recipe commences before first target. Stop.'
> > 'missing rule before recipe. Stop.'
> >      This means the first thing in the makefile seems to be part of a
> >      recipe: it begins with a recipe prefix character and doesn't appear
> >      to be a legal 'make' directive (such as a variable assignment).
> >      Recipes must always be associated with a target.
> 
> While that phrasing doesn't rule out subsequent targets from starting
> with a TAB, empirically that seems to be the case:

I didn't say a _rule_ can start with a TAB, I said a rule's _line_
could start with a TAB.  For example (indentation added for
readability):

  foo \
	  bar: baz

bug#46052: Colons fooling GNUmakefile mode

[Kévin Le Gouguec]

Eli Zaretskii <eliz@gnu.org> writes:

> I didn't say a _rule_ can start with a TAB, I said a rule's _line_
> could start with a TAB.  For example (indentation added for
> readability):
>
>   foo \
> 	  bar: baz

Thanks!  I suspected there could be cases I hadn't thought of; sorry to
have misunderstood your point.

FWIW, right now make-mode seems to fail to fontify your example
correctly, ironically: I'm not seeing any face applied to the target
("foo \\\n\tbar").

bug#46052: Colons fooling GNUmakefile mode

[Eli Zaretskii]

> From: Kévin Le Gouguec <kevin.legouguec@gmail.com>
> Cc: jidanni@jidanni.org,  46052@debbugs.gnu.org
> Date: Sat, 23 Jan 2021 18:59:48 +0100
> 
> >   foo \
> > 	  bar: baz
> 
> Thanks!  I suspected there could be cases I hadn't thought of; sorry to
> have misunderstood your point.
> 
> FWIW, right now make-mode seems to fail to fontify your example
> correctly, ironically: I'm not seeing any face applied to the target
> ("foo \\\n\tbar").

I wrote that to prevent people from installing a too-simplistic
solution.  I had no idea whether this is correctly supported
currently.