Re: makefile-mode font-lock bugs and annoyances

[Daniel Pfeiffer]

la 08.06.2005 19:02 Glenn Morris skribis:

> Since it doesn't seem to be going away (despite this thread where
> nobody liked it:
> <http://lists.gnu.org/archive/html/emacs-devel/2005-05/msg00758.html>;
> and several poeple asked for the changes to be reverted), here is a
> list of problems with the latest makefile-mode.
>
>
> Font-lock bugs:
>
> 1. In constructs such as:
>
> ARCH       = $(shell uname -s)
>
> "shell" is highlighted as a variable when it is not. Emacs-21.3 gets
> this right.
>  
I don't know where that came from. This worked right when I did it, then 
a change in the Emacs display engine (something about overriding face 
attributes) seemed to have broken it, but before I found time to analyse 
and report it, it was working right again.

> 2. Highlighting of conditional constructs is broken:
>
> ifdef FOO
>   blah
> else
>   blah blah
> endif
>
> i) FOO does not get highlighted as a variable. Emacs-21.3 gets this
> right.
> ii) ifdef / else / endif do not get highlighted as keywords.
> Emacs-21.3 gets this right.
>  
This is correct, because ifdef et al. are not keywords for make! The old 
makefile-mode mixed up make, gmake and automake, not allowing you to see 
when you wrote stuff for the wrong make into a makefile. In Emacs' own 
makefiles for example ifdef must *not* get highlighted for this very 
reason. (Maybe it should even signal an error when you type it, so you 
really notice :-)

The problem here is that for backwards compatibility gmake will read in 
a Makefile when there is no GNUmakefile. That made some people get 
sloppy and actually write gmake constructs into plain Makefiles. There 
is a keybinding C-c C-m C-g for quickly switching to makefile-gmake-mode 
in such a case. There you get what you are looking for.

> Annoyances. These are all IMO.
>
> 1. makefile-shell-face is incredibly ugly.
>
> Eg in the following:
>
>   cd $(bindir) ; \
>   rm -f $(targets)
>
> I see a spoldge of grey background extending from "cd" through to the
> right-hand edge of the display on that line, and from column 0 in the
> "rm" line to the end of the text. Yuck. Moreover, I don't think it
> serves any useful purpose.
>  
If you don't think the extra information font-lock gives to the eye 
serves any useful purpose, don't use it. Here we have one little 
character at the end of the first line which makes a huge difference as 
to what gets passed to the Shell. I find it very useful to see at a 
glance that the two lines (in some makefiles dozens of lines) are in 
fact one. As for the face, I chose a background colour so it wouldn't 
collide whith any variable, function etc. highlighting. And the colour 
name, seashell, was just too tempting for a Shell command.

The other aspect is that makefiles marry two completely different 
languages, their own and Shell (and in the case of makepp even Perl as a 
third). Font locking like this makes it easy to tell them apart instantly.

> 2. With something like:
>
> clean :
>      -rm -f *.mod *.o $(targets)
>
> The "-" before "rm" gets highlighted in font-lock-type-face. This is
> just silly.
>  
It's definitely not part of the command, so it must look different! In a 
way it's a keyword, though it's not even a word. It marks a special type 
of command that may fail. Likewise @ marks a type of command that gets 
hushed up. I think introducing a makefile-command-modifier-face for two 
characters might be an overkill. Especially since font-lock doubles each 
face as a variable, so you can set this locally to anything in 
makefile-mode-hook.

> 3. $@ gets highlighted with makefile-targets-face. I'd prefer it to be
>   treated as a variable, as it used to be, because... it's a
>   variable.
>
> 4. Ditto for $^, which gets font-lock-constant-face at present.
I don't know why, but when I took over makefile mode, single character 
variables were already highlighted differently from parenthesized 
multiletter ones. I feel that to be wrong, but I didn't care since in 
makepp every single character variable has a long alias which I always 
use, so I don't see these. As for target face, that is an additional 
face for $@ because it's not only a variable but also the target. That's 
why it's underlined, so it can be combined with variable face, which has 
a foreground colour and shell face, which has a background colour.

coralament / best Grötens / liebe Grüße / best regards / elkorajn salutojn
Daniel Pfeiffer

--
lerne / learn / apprends / lär dig / ucz się    Esperanto:
                             http://lernu.net/