emacs-pretest-bug
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: makefile-mode font-lock bugs and annoyances


From: Daniel Pfeiffer
Subject: Re: makefile-mode font-lock bugs and annoyances
Date: Thu, 09 Jun 2005 21:14:41 +0200
User-agent: Mozilla Thunderbird 1.0.2 (X11/20050317)

la 09.06.2005 16:23 Glenn Morris skribis:
Daniel Pfeiffer wrote:
 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.
    

I don't know what you mean by "working right again". It's broken for
me in the current CVS.

Oh, hang on, I see. It's another one of those wonderful things where I
have to switch to "Gnumakefile".                 

  
This is correct, because ifdef et al. are not keywords for make!
    

Others have commented on this, and FWIW I agree with them.
  
Like I said, I'll solve this more intelligently.
If you don't think the extra information font-lock gives to the eye
serves any useful purpose, don't use it.
    

I'm not going to. I'm going to spend my time customizing make-mode to
make it look how it used to, because I think the new defaults are so
bad.
  
That's the nice thing about freedom.  :-)  And you'll still have correct recognition of 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!
    

"must" is a bit strong here, don't you think? I've lived quite happily
for years without this. Personally, I'm sticking with my "just silly"
assessment! :)

I think we want different things from font-lock. I want certain
important features highlighted, you seem to want almost everything
highlighted. Or else we disagree about the definition of "important".
  
It's always a matter of taste.  But if you have things side by side which go to totally different directions, why not hint at this visually?  What else is font-locking for if not to make you notice differences...
  
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.
    

How wonderful for you. The rest of us should just sort ourselves out
then, should we?
  
Hey cut it out!  If it bothers you, why didn't you complain or do something about this 10 years ago?  On the one hand I get flamed for having changed make-mode, and then right afterwards I also get flamed for not having changed it.
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.
    

Three different kinds of font-locking in the same place?!
Net result: nausea.
  
Sorry, makefile hodge podge itself is nausea.  This gets passed to the shell, it's a variable and it refers back to the target.  By combining a foreground, a background and another attribute (underline) there's no collision, and each bit transports meaningful information.
We're basically arguing over defaults, which seems to be generally
fruitless. I just found the new ones so bad, I was motivated to say
something.
I don't understand how you ever tolerated the old mode.  It got maybe every second makefile I dealt with at work wrong...
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/

reply via email to

[Prev in Thread] Current Thread [Next in Thread]