That part is trivial and I would have already done this on friday. You
just have to replace makefile-mode with makefile-gmake-mode in files.el
in the branch which is not for BSD. For *.mk files I had done it that
way from the beginning.
Please do that.
Here are two other
For another, when you load a .h file it comes up in C mode, even though
enough .h files contain C++. Nobody would write class or template or even
import or interface in C file, so why not have a superset of C, C++ or Java
in one mode? That would be the same as having all makefiles in gmake
la 12.06.2005 01:16 Richard Stallman skribis:
After that statement, this one is rather
unclear. Are you trying to tell me you reconsidered?
I did not reconsider. I described (more orless) the same goal in two
different ways. Handling of GNU extensions should be enabled by
default.
la 12.06.2005 17:53 Stefan Monnier skribis:
For another, when you load a .h file it comes up in C mode, even though
enough .h files contain C++. Nobody would write class or template or even
import or interface in C file, so why not have a superset of C, C++ or Java
in one mode? That
la 11.06.2005 00:37 Richard Stallman skribis:
As GNU-make is upward compatibile with traditional make, this makes the
implementation easy: just highlight GNU-make extensions by default, no
mode-setting or whatever is necessary.
Daniel, that's how I want it to work.
For one thing you
I thought that having the new faces attributeless by default, and
handling extensions (i.e. gmake, ...) even when the filename doesn't
indicate it, would be enough to keep everybody happy...
It might be so, but I am not sure. That is why I am looking for someone
who wants to take
Daniel Pfeiffer [EMAIL PROTECTED] writes:
Or put another way, what part of the file is fontified _incorrectly_
if treated as a GNU Makefile?
ifdef, $(patsubst) and all that.
Sorry, but I don't see _any_ ifdef or patsubst in emacs' makefiles.
Not using those features doesn't mean that the
People are very unhappy with the changes that you made, so I am going
to look for someone to undo part of the changes. Parts of the changes
may be good; the thing is to find the good parts.
I don't have time to do that myself. All I could do is revert them
all, since that would be quick. I
la 10.06.2005 15:29 Richard Stallman skribis:
People are very unhappy with the changes that you made, so I am going
to look for someone to undo part of the changes. Parts of the changes
may be good; the thing is to find the good parts.
I don't have time to do that myself. All I could do is
Daniel Pfeiffer [EMAIL PROTECTED] writes:
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.
If you're going to use a background color for this sort of
Daniel Pfeiffer [EMAIL PROTECTED] writes:
2. Highlighting of conditional constructs is broken:
ifdef FOO
blah
else
blah blah
endif
...
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
Daniel Pfeiffer wrote:
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.
I don't
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
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.
And for what it's worth, I'll reiterate that I agree with you. It's good to
fix make-mode so it highlights more correctly (parses the various funny
la 09.06.2005 09:40 Miles Bader skribis:
Daniel Pfeiffer [EMAIL PROTECTED] writes:
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.
la 09.06.2005 13:37 Kim F. Storm skribis:
Miles Bader [EMAIL PROTECTED] writes:
It's a fact of life that many, many, people use the name "Makefile" for
GNU-make-only makefiles, and if anything this practice has spread
greatly in recent years (I think I've only seen "GNUmakefile"
Daniel Pfeiffer wrote:
Like I said, I'll solve this more intelligently.
I really don't think this is the time to be doing this. Emacs is
supposed to be a feature freeze state so it can be released sometime.
Admittedly, it's not clear how anyone is supposed to recognize this...
I'm sure your
No new statements in this post; just noting my agreement with the
following bits:
I'm sure your new make code has lots of improvements under the hood,
but:
i) the surface appearance puts me off it completely. Yes, I'm shallow.
ii) the timing is bad.
iii) the lack of consultation is bad.
la 10.06.2005 00:20 Kim F. Storm skribis:
Daniel Pfeiffer [EMAIL PROTECTED] writes:
The default for emacs should be to treat ALL makefiles as GNU makefiles.
Emacs own makefiles are not GNU make, being auto* based it uses plain
make as do many other GNU
On 6/10/05, Daniel Pfeiffer [EMAIL PROTECTED] wrote:
Myself I actually use a bit gaudier seashell2, but I did set the defaults
to a very light seashell1 and very dark seashell4.
It's still not subtle enough though -- reading any of the recent
threads about makefile-mode should make it clear
la 09.06.2005 21:39 Glenn Morris skribis:
Daniel Pfeiffer wrote:
Like I said, I'll solve this more intelligently.
I really don't think this is the time to be doing this. Emacs is
supposed to be a feature freeze state so it can be released sometime.
Admittedly, it's not
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.
This is not incorrect.
In general, I think you are trying to reason
Daniel Pfeiffer [EMAIL PROTECTED] writes:
Nothing fancy, just statements like ifdef at bol, or $(patsubst ...) et
al, would mean gmake, .ifdef at bol bsdmake...
That's not really good enough though. The presence of a GNU-make
extension _anywhere_ in the file means it's a GNU-makefile.
As
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
24 matches
Mail list logo
