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
Ralf Angeli [EMAIL PROTECTED] writes:
emacs -Q -eval '(setq debug-on-error t)'
a debugger window with the following message pops up:
Debugger entered--Lisp error: (void-variable flyspell-mode)
Yesterday, I changed flyspell.el. As a result the var flyspell-mode
is not autoloaded anymore.
In [emacs-w3m : No.08153] Katsumi Yamaoka wrote:
(with-temp-buffer
(insert-char ?- 70)
(let ((fill-column 70)
(adaptive-fill-mode t))
(fill-region (point-min) (point-max
= fill-prefix too long for specified width
Is it reasonable that the form causes an error? Similar
* Lute Kamstra (2005-06-09) writes:
Ralf Angeli [EMAIL PROTECTED] writes:
emacs -Q -eval '(setq debug-on-error t)'
a debugger window with the following message pops up:
Debugger entered--Lisp error: (void-variable flyspell-mode)
Yesterday, I changed flyspell.el. As a result the var
Ralf Angeli [EMAIL PROTECTED] writes:
In loaddefs.el there are some references to the variable
`flyspell-mode' in code related to menus.
Yep, it seems that ispell.el is the culprit. I'll install a fix.
Thanks,
Lute.
___
Emacs-pretest-bug
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
With parse-sexp-ignore-comments t and point in between ( in
(setq foo (;))
forward-sexp does not know anything about the surrounding context.
I don't think of this as a bug; this is what it is supposed to do.
___
Emacs-pretest-bug mailing
screen.c was probably renamed to frame.c when we changed screen
to frame in the API.
Anyway, since that arg was never documented, and is not really used
except in the C code where the callers MUST pass it, I would not mind
deleting the argument.
___
Since both mode-line-inactive and mode-line-highlight are
new faces in 22.x, do we really need to have face aliases
for them?
These aliases are not needed for backwards compatibility,
but I see no harm in supporting anyone that forgets to type
the hyphen.
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
When I start an Emacs with -Q (the Carbon port, recent CVS compile),
then do
(add-hook 'after-change-major-mode-hook
(lambda () (message (format New mode: %s major-mode
and then do M-x sh-mode, I would expect to see New mode... at least
in the *Messages* buffer.
I don't get that;
On 9 Jun 2005, at 17:25, David Reitter wrote:
When I start an Emacs with -Q (the Carbon port, recent CVS
compile), then do
(add-hook 'after-change-major-mode-hook
(lambda () (message (format New mode: %s major-mode
and then do M-x sh-mode, I would expect to see New mode... at
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.
While I'm not sure of it since I don't use the adaptive-fill-mode
normally, I found something like a bug. Try the following:
(with-temp-buffer
(insert-char ?- 70)
(let ((fill-column 70)
(adaptive-fill-mode t))
(fill-region (point-min) (point-max
= fill-prefix too long
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
In [emacs-w3m : No.08172] Stefan Monnier wrote:
Does the patch below fix your problem?
Very good. It seems to be a right course not to look back on
paragraph-start in that situation. Furthermore, ignoring long
prefix completes it. Could you please install it?
Though we can solve it for
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
Richard Stallman wrote:
Anyway, since that arg was never documented, and is not really used
except in the C code where the callers MUST pass it, I would not mind
deleting the argument.
Done.
Sincerely,
Luc.
___
Emacs-pretest-bug mailing
26 matches
Mail list logo
