I agree that signaling an error is better than xassert.
But, it seems that a function in selection-converter-alist
can return a multibyte string as long as we have a fixed
rule about how to handle it. And converting to a unibyte
string by string-make-unibyte seems to be a good rule.
+ (defun regexp-builder ()
+ Alias for `re-builder': Construct a regexp interactively.
+ (interactive)
+ (re-builder))
Why not just
(defalias 'regexp-builder 're-builder)
-- Stefan
___
Emacs-pretest-bug mailing list
The initial value of blink-cursor-mode is set using the value of
emacs-quick-startup when noninteractive is nil.
:init-value (not (or noninteractive
emacs-quick-startup
(eq system-type 'ms-dos)
(not (memq window-system '(x
Trying to get it to use
Lucida Grande, I put
(set-face-font 'default -apple-lucida
grande-medium-r-normal--12-140-75-75-m-120-mac-roman)
You usually shouldn't use `set-face-font'; instead set the various
other face attributes.
Does that mean we should mark set-face-font as obsolete?
Also, looking at the code of set-face-font, it doesn't do aything else than
call (set-face-attribute face frame :font font), so I doubt it will give
much better results.
Well what I mean to say was you shouldn't call set-frame-attribute
:font either. :-)
It's often convenient to set :font
Thanks - I put the save-excursion in redraw-calendar itself.
For some reason I though with-current-buffer would preserve point.
with-current-buffer doesn't preserve point. But note that
(save-excursion
(set-buffer foo)
...)
doesn't quite preserve point either: it preserves point in
The guillemets , , and should all be punctuation. The single
ones currently have word syntax, and the double ones are treated as
parens in latin-{1,5,9}.el.
As I don't use those characters, I don't know what is
correct. But, it seems that they are used as a pair; isn't
it convenient if
Maybe a workaround is to give them generic string fence syntax (aka |)?
[That hasn't got to me.]
It seems to be a good idea. Are there any objection?
That isn't correct. There is a comment somewhere in the doc or code
about quotation marks intentionally _not_ having string syntax in text
However, as far as I remember, it needn't be confined to GTK. I think
the Lucid and Motif menus should be able to display utf-8 in a utf-8
locale, at least with recent enough XFree86/X.org for Lucid. I don't
recall the details, though, and I think the Lucid menu code needs
fixing in some
Maybe a workaround is to give them generic string fence syntax (aka |)?
It seems to be a good idea. Are there any objection?
That isn't correct. There is a comment somewhere in the doc or code
about quotation marks intentionally _not_ having string syntax in text
modes or globally.
Which
To make reliable judgement about the display state, line-move must
call sit-for which does redisplay.
That is a really bad problem.
IMO, it is not too bad -- line-move is primarily (solely?) for
interactive use, so redisplay will happen after the command
anyway.
Agreed.
We need to
But maybe it's important to be able to compute the matrix without *ever*
displaying it. E.g. in fit-window-to-buffer, count-screen-lines is used to
decide how to resize the window.
In the case where the matrix will be displayed sooner or later, I don't
think it makes much sense to delay the
(eq (substring fred 0 1) (substring fred 1 2))
nil
`substring' creates/allocates a string, so (eq (substring ...) ...) will
*always* return nil.
`eq' is pointer equality, whereas `equal' is structural equality.
Stefan
___
Emacs-pretest-bug
What I currently see in my Lucid menu is a question mark. Is that what you
mean by junk?
No, I meant basically random characters. Question marks would be
better. Maybe something has changed; I can't check at present. I
can't remember how it is (or was) and what cleanup was rejected, but
That isn't correct. There is a comment somewhere in the doc or code
about quotation marks intentionally _not_ having string syntax in text
modes or globally.
Which comment in which code?
I don't know, or I'd have referenced it. I guess rms can comment on
the intent.
I guess this answer
As someone who doesn't have a background in Lisp, I would expect executing
the same statement three times to give the same result as executing three
identical statements. Perhaps its a bit like quantum mechanics, in that,
once you've passed the stage of disbelief, you can no longer see what
!;; Return `mode-name' if not blank, `major-mode' otherwise.
!(if (and (stringp mode-name)
! ;; Take care of preserving the match-data because this
! ;; function is called when updating the header line.
! (save-match-data
!
With emacs -Q, smerge-ediff is fully documented, and can be invoked
interactively.
After loading pcvs, it is undocumented, and cannot be invoked
interactively. This is a minor irritation, since smerge-mode now has
to be loaded by hand before interactive use of smerge-ediff.
Duh! Thank
On the machines here, the default ispell dictionary is French.
This confuses flyspell as the example below shows:
% emacs -q ~/tmp/foo.txt
M-x flyspell-mode RET
chocolat
chocolate
problème
the first word is accepted as correct while the second is highlighted
as a typo
When I'm executing a shell-command-on-region I receive beside the result
also that notice:
stty: stdin isn't a terminal
What does that mean?
Google should be able to answer that one. It's a problem in your shell's
config file (like .cshrc) where you use `stty' without first checking
Could you try with completely vanilla Emacsen (i.e. no extra package from
/Library/Application Support/Emacs, no .emacs, ...). The most likely
problem is that some code somewhere calls standard-display-european.
Renaming /Library/Application Support/Emacs I have in GNU Emacs 22.0.50's
I don't have .Xresources -- but as I said in my previous mail,
the message did change to
Warning: Cannot convert string -*-helvetica-medium-r-*--*-120-*-*-*-*,*
to type FontSet
but the menu bar font is still wrong...
Unless/until someone can help me fix this, could someone just take
(modify-syntax-entry ?\= _ b12 st) ; comment start ==
Yes, it seems the problem is that your 2-char comment sequence is made of
symbol-chars, so there are cases where the code does things like oh, here's
a symbol, let's skip it without checking whether some of the chars that
compose the
python.el ends the current block if a line starts with return.
However, it doesn't checkt whether this is followed with _. So,
if I write
return_count = 4
python.el closes the current block wrongly.
I've installed Dave's suggestion in Emacs-CVS. Can you confirm that it
fixes your bug?
This problem currently prevents AUCTeX users from marking LaTeX
environments as long as icomplete-mode is active.
It only prevents them if they use M-x ..., not if they use a key-binding to
mark the environment, right?
Yes.
Does the patch below help?
Yes, it does. Thanks very much for
In the shell, the text wraps around to the next line, which is acceptable.
This is not the case for Emacs windows split vertically with C-x 3 or ECB.
Try (setq truncate-partial-width-windows nil)
On my system, the emacs.py rlcompleter interface works correctly and
outputs a string, but
(defvar nero-link-regexp \\[\\([0-9]+\\)\\]
(defvar nero-font-lock-keywords
(eval-when-compile
(list `(,nero-link-regexp . font-lock-keyword-face)))
When byte-compiling, nero-link-regexp will be compiled (i.e. some code will
be output for it) but not evaluated (the variable is not
I think that running ogg123 on a .ogg file in the shell will do it. I
think running wget asynchronously to download a big file will do it.
If you are handling 3+M files, the warning is to be expected.
Actually, I don't see any reason why Emacs should complain about it.
Most likely what
Curiouser and curiouser. I put a message in
python-preoutput-filter that echoes its parameter as you
suggest. Looking at the contents of my messages buffer after
attempting the completion for os., the Can't find completion
message from the python completion routine happens after
precisely
You can always fix these problems locally by setting or binding
deactivate-mark in the particular place. WOuld you please fix it that
way?
Because I just compiled a fresh CVS checkout of Emacs and still see
the problem and haven't found a check-in by Stefan related to the
(setq font-lock-keywords '((foo . bold)))
This shouldn't be a face symbol but an expression (whose value is typically
a face symbol). I.e.:
(setq font-lock-keywords '((foo (0 'bold
-- Stefan
No, it's just an expression -- for the standard font-lock faces there
are variable names that are _exactly_ the same as the face names,
which evaluate to the corresponding face name.
[I think this is silly and confusing, but font-lock is very old...]
But as you know, this has proved
(defun python-preoutput-filter (s)
`comint-preoutput-filter-functions' function: ignore prompts not at
bol.
(cond ((and (string-match (rx (and string-start (repeat 3 (any .))
I see you've reverted to the basic code and thus removed the while loop
I had added.
I guess it's OK so
that would have required buffer-local faces (which we still
don't have: any progress on this side?)
They've worked great in my emacs for ages and ages; I use them daily... :-/
I know, but I still can't see any trace of it in the CVS :-(
Stefan
I recently suggested patches to report menu bindings using the real
menu item texts rather than the internal names, like this:
File=Print=Print With Faces
But Richard didn't want that feature (why not?).
I agree it would be an improvement. But IIRC you did it by modifying
I don't know about you, but when I do here
emacs -Q
or
emacs -nw -Q
in either case, standard-display-table is not nil,
Why is that? It is nil for me.
Probably the locale. I have LANG=fr_CH.ISO-8859-1.
Admittedly, the fr_CH population is small, but the
With my patch, (key-description KEY t) will do just that.
Making C-h c using that is trivial (I already did so).
Great, then I strongly support it.
C-h k File New File... reports:
,--
| File=New File... runs the command find-file
|which is an interactive
It doesn't bother me this much :-), I've been using
mouse-autoselect-window for a quite a while now and 2 days ago was the
first time, that I noticed this behavior. But then again I'm hardly using
the menu bar (and I've never used the tool bar).
That's the problem: with the select on no-move
Hm, it now was surprisingly hard for me to reproduce it. Surprising
because when I wrote the bug report I was annoyed by it happening so
often. It seems to happen only when there is an active selection,
e.g. a part of the buffer marked by dragging with mouse-1. (I
normally have
(gdb) r -q -xrm 'Emacs*fontSet: -*-helvetica-medium-r-*--*-120-*-*-*-*-*-*,*'
Starting program: /home/kfs/fsf/latest/src/emacs -q -xrm 'Emacs*fontSet:
-*-helvetica-medium-r-*--*-120-*-*-*-*-*-*,*'
Warning: Missing charsets in String to FontSet conversion
Warning: Cannot convert string
The use of custom-current-group seems like a bad practice to me.
[...]
The reason for that is that most of the time the default group chosen
by define-minor-mode is a bogus group without one of the major groups
as its ancestors.
The whole point of the use of custom-current-group is to try
But, I guess that at the present state it will be difficult to do that
and get rid of `custom-current-group', because many things already
rely on `custom-current-group'. What we definitely could and, I
believe should, do is discourage people from relying on it, because it
is quite simply not
BTW, I googled for Missing charsets in String to FontSet conversion.
Similar problems have been reported for several other applications.
The missing charset is just a warning.
But the Cannot convert string ... to type FontSet is a hard failure.
Stefan
rms didn't like this new behavior so the second patch I posted (and
did not install yet) merely changes the behavior of define-major-mode
back to the situation before 2005-03-31. So implying that my (second)
patch has big consequences is not really fair.
I didn't realize you hadn't installed
* diff-mode.el (diff-minor-mode): Specify :group.
* font-core.el (font-lock-mode): Specify :group.
* reveal.el (reveal-mode): Specify :group.
* smerge-mode.el (smerge-mode): Specify :group.
[...]
Does it make sense to have a :group for buffer-local minor modes?
(gdb) r -q -xrm
Emacs*fontSet: -*-helvetica-medium-r-*--*-120-*-*-*-*-*-*,*'
Starting program: /home/kfs/fsf/latest/src/emacs -q -xrm
Emacs*fontSet: -*-helvetica-medium-r-*--*-120-*-*-*-*-*-*,*'
Warning: Missing charsets in String to FontSet conversion
Warning: Cannot convert string
$ ./missfonts
$ ./missfonts -*-helvetica-medium-r-*--*-120-*-*-*-*-*-*,*
Missing 0: ISO8859-1
$ ./missfonts -*-helvetica-medium-r-*--*-120-*-*-*-*,*
Missing 0: ISO8859-1
The xfs configuration doesn't list any ISO8859-1 fonts:
Somewhere, specifying UTF-8 requires ISO8859-1 ?
So it seems
The problem is triggered in vhdl-template-field, it seems that
read-from-minibuffer switches to the point position of the wrong window.
I don't know how to fix it, but I've traced it to the following problem:
% emacs -Q
[ type in some random text]
C-x 2
[ move point elsewhere ]
M-:
Functions that expect an argument to be a position (an integer), but accept a
marker as a substitute, normally ignore the marker buffer.
The meaning of this sentence isn't clear to me.
If marker M points to position P in buffer A and you're in buffer B,
(goto-char M) will go to position P in
Now, press `C-c C-c' inside the entry -- Emacs suggests `blöd05:_test'
as the key to use -- and hit RET: Emacs writes in the minibuffer `New
inserted entry yields duplicate key'.
Does the patch below fix the problem for you?
Stefan
--- bibtex.el 26 jan 2005 14:25:43 -0500
+int marker_pos = -1;
This should be EMACS_INT, since Lisp_Object can be 64bit even if int is
only 32bit (and it should be in the MARKERP branch of PRINTPREPARE rather
than in PRINTDECLARE).
Stefan
PS: Yes, it's a very widespread problem, but if we ever want to be able to
How do you input the ö?
I just press the 'Ö' key on my keyboard!
The problem is that the ö you type at the isearch prompt is a latin-1
ö whereas the one in the buffer is a latin-9 ö (Emacs's internal
representation of characters has such duplicates).
Try M-x unify-8859-on-decoding-mode RET
I don't know how to fix it, but I've traced it to the following problem:
% emacs -Q
[ type in some random text]
C-x 2
[ move point elsewhere ]
M-: (save-window-excursion (select-window (next-window))) RET
after the M-: command, point in the second
the patch fixes the reduced error, but not the original problem.
Can you try the patch below instead?
It seems to fix it for me *and* it explains why font-lock-mode is
a necessary ingredient.
Stefan
--- window.c02 mar 2005 22:20:12 -0500 1.496
+++ window.c12 avr 2005
In what xterm did you test these? I remember vaguely that I tried in
the past to add more bindings to xterm.el, but abandoned the idea
after I discovered that different flavors of Unix had xterm's that
used incompatible bindings.
Luckily, tho the bindings are sometimes different, they
Any objection/adjustment?
In X11 in an ISO 8859-1 buffer it works to i-search (and find) for ä,ö,ü,Ñ,í
... but: in an ISO 8859-2 buffer it fails to find ° (degree).
[... more cut ...]
Sorry, you went too fast for me. Could you restate the problem with more
details of what you did? To start
Would it be acceptable to add something like:
(substitute-key-definition [f29] [C-f5] function-key-map) to xterm.el?
Would it work?
I thought the translation from esc-sequence to f29 is already done by
function-key-map (with elements added by reading the terminfo data) and
you function-key-map
I think I got the reason for this behaviour:
'(unify-8859-on-decoding-mode t nil (ucs-tables))
I'm not sure I completely understood your previous mails, so
just to be sure, here is what I believe to be what you said:
- emacs -q in a latin-1 locale has problems isearching for an
é in a
With your patch to keyboard.c it does not work, i.e. i-search é does not
find the character in my test file ISO 8859-15.txt, without the patch it
works, i.e. i-search finds é.
unify-8859-on-decoding-mode's value is t.
Hmm, it works for me. Could you pretty please give an actual R.E.C.I.P.E
Check unify-8859-on-decoding-mode's value: C-h v unif TAB de TAB RET ==
nil
Open the directory with test files: C-x d ~/ISO TAB RET
Click with mouse-1 the ISO 8859-15 test file == opens writable in new
buffer
I-search that accented e: C-s ´e RET == success, é found!
Close that buffer:
I think the patch below that I just installed fixes it,
Are both of your patches needed, emacs/src/keyboard.c +
emacs/lisp/international/ucs-tables.el?
They're unrelated. They both fix different cases.
Stefan
___
Emacs-pretest-bug
I think I agree now that the patch you installed is a bug fix
and correct.
Good, thanks.
The problem that point moves after
(save-window-excursion (select-window (next-window)))
That's the problem I saw reported.
No, the problem is not that point is moved, but that the window's cursor
is
No, I can't. But shouldn't we avoid such an incompatible
change at this stage?
Can be. But since it's about a year now since we called a freeze and I see
no sign of getting to the pretest stage, I figure I don't understand enough
what feature freeze means: I just propose changes and I'll let
When I dired a directory with files from March I see something like this:
-rw-r--r--1 pete pete2688 7 Mär 16:19 slh-inst.log
Do you also get that with emacs -q --no-site-file?
Stefan
___
Emacs-pretest-bug mailing list
Would it be acceptable to add something like:
(substitute-key-definition [f29] [C-f5] function-key-map) to xterm.el?
Would it work?
As I said in another message substitute-key-definition works, and the
reason why it would be needed is what you just stated above.
Duh, I didn't pay
I'm saying that changing it to
(save-excursion (save-window-excursion (select-window (next-window
ought to solve the problem too, and the approach is less risky.
That's true. But what about:
(save-window-excursion (forward-char 1) (select-window (next-window)))
I'd
I have a hard time believing you tyhink this behavior is desirable.
So just to double check: you do realize I'm talking about the window's
cursor.
I am not sure if that statement is meaningful. Remember, the window's
point value is never in use for the selected window.
I know
Contrary to what I wrote in my previous mail, the problem is not in the
file-newer-than-file-p function but in the calls to it in pcvs-info.el,
at function cvs-fileinfo-backup-file
The concatenation of dir should only done on the single result at the end
and not within the loop.
Thanks for
cperl-mode 5.0-Emacs does not properly parse POD, regular expressions,
or q* operators. When I start emacs -Q and enable font-lock-mode and
load the following program under cperl-mode, the regular expression is
not properly parsed and highlighted (if I were to insert a ' into it,
it would
in CVS Emacs but the default value for focus-follows-mouse appears to be
wrong (t) on MS Windows systems.
Indeed, it seems wrong.
I don't believe there is an option that will cause focus to follow a mouse
on MS Windows systems.
Actually there is (thank god), using the PowerUI or
On the slowest machine that I have access to, a 500MHz P3 the
xterm.elc load time (as reported by elp) goes from 2.2 seconds to 0.3
seconds if all the substitute-key-definition calls are moved before
(let ((map (make-sparse-keymap)))
That's a good point: the keys we want to substitute are
Nick == Nick Roberts [EMAIL PROTECTED] writes:
xterm.el makes Emacs take about seven times as long to load for me (about 14
seconds on my 200MHz PC). I have tested this by setting term-file-prefix to
nil as described in startup.el
I think this is due to the recent changes in xterm.el e.g
Stuff like mouse-extend mainly. But I noticed that it's enough to just
(require 'mouse-sel), but not activate the mode - so that's what I'm doing
now. That's obviously a workaround, not a fix...
If doing nothing more than (require 'mouse-sel) already modifies the
behavior of Emacs, it's a bug
If you do something like
M-x cvs-examine RET /home/tmp/emacs RET
go on one line, then use
C-u C
to get a Log edit buffer, then do a kill-buffer of the original *cvs*
buffer, switch to some arbitrary buffer and do
M-x cvs-examine RET /home/tmp/emacs RET
again, then the *cvs-commit* buffer
David == David Kastrup [EMAIL PROTECTED] writes:
This bug report will be sent to the Free Software Foundation,
not to your local site managers!
Please write in English if possible, because the Emacs maintainers
usually do not have translators to read other languages for them.
Your bug
Both `hack-local-variables' and `hack-one-local-variable' may call
`switch-to-buffer' when parsing local variables. As a consequence, a
save-window-excursion: Cannot switch buffers in a dedicated window
error is generated when calling `find-file-noselect' while the
selected window is
Hm, this might be a knock-out criterion for the usage of menu filters
or hooks in order to ask the user for a master file of a multi-file
LaTeX document.
Indeed. Why do you want to do it from a menu-filter? It sounds like an odd
idea to start with.
OTOH, you say that the filter is run
So we searched for a way to delay the question about the master file
until this information is actually needed in the editing process. One
of these events is when the user opens the menu for inserting a LaTeX
environment or macro.
I understand. I do think the current behavior of menu
Is there any reason that $ does not have a `.' (punctuation) syntax
class in sh-mode?
Just . would be wrong IMNSHO (because C-M-b wouldn't properly jump over
$BLAH). I'd vote for . p or ' syntax. Not sure between the two.
The current w is clearly wrong and should at least be changed to _.
Is there any reason that $ does not have a `.' (punctuation) syntax
class in sh-mode?
Just . would be wrong IMNSHO (because C-M-b wouldn't properly jump over
$BLAH). I'd vote for . p or ' syntax. Not sure between the two.
A little bit of testing showed that none of the above required
(eval-when-compile (require 'cl))
If I do load-library RET gud RET
then gud is loaded and cl is not, as you would expect.
Try M-x load-library RET gud.el RET and discover that your problem has
nothing to do with eval vs load but with source vs byte-compiled code.
Stefan
Upon opening, some makefiles are causing Emacs to begin 100% CPU
utilization for an unacceptably long time (minutes).
My crystal ball tells me it's a regexp that exhibits bad
backtracking behavior. The fact that it only occurs when font-lock is ON
means it's a regexp in
Quitting rings the bell because you do it with the bell character,
C-g. Also, it works by causing something almost indistiguishable from
an error.
Of course we could distinguish them. I do think it's important to do
something when execution is interrupted by C-g so the user can tell the
+ (and url-callback-arguments
+ (cdr url-callback-arguments
Since (cdr nil) = nil, you can simplify this
to just (cdr url-callback-arguments).
Stefan
___
Emacs-pretest-bug
- ido starts looking for the file everywhere according to some
algorithm I dont know, something like locate.
- This is annoying and time consuming, so i press c-g. However, ido
doesnt stop looking, so I get annoyed and press c-g several times
quickly.
I recommend the use of while-no-input
This is the output from gdb:
as i586-suse-linux...Using host libthread_db library
/lib/tls/libthread_db.so.1.
(gdb) run
Have you tried with -q --no-site-file?
Stefan
___
Emacs-pretest-bug mailing list
Emacs-pretest-bug@gnu.org
I'm now working on both a mac laptop and a gnu/linux desktop system, and
I pull the emacs session from the desktop to my laptop for work. This
means I run the linux variant on the Mac screen/keyboard. There is a
small problem with running emacs on macintosh keyboards which is
solvable via
The backtrace I get when I type bt is 84000+ lines.
When? If Emacs seems to hang, it means it's stuck in an (almost-)inf-loop,
and you can try stopping it a few times and compare the backtraces.
The one you show was taken from within the GC, which always leads to such
long lists of
The attached file contains the top and bottom of a Lisp backtrace I got from
C-g, after enabling enter debugger on quit.
Indeed it looks like a loop/recursion bug in EDE.
So can we conclude that emacs does not _crash_ ?
And since C-g works as well, it's not frozen.
I.e. it's not an Emacs
The same argument could be made for *Help*, or Dired, or *Apropos*, or
*Buffer List*, or Those buffers don't use TABs, but there is no
restriction on their use or any explicit enforcement to not use TABs,
AFAIK.
AFAICT these are different situations: the TABs in info buffers don't come
The hooks in after-change-functions seem to be called even when I just open
a menu from the menu bar with the mouse (before even selecting a menu
item!). Clearly, no change has been made to the buffer in such
a situation. I think that after-change-functions shouldn't be called.
I think the only feasible fix for this problem is to turn off the new
feature of highlighting the value assigned to the make macro, and go
back to highlighting only the macro name.
Yes, please.
It is sort of unfortunate, but I don't know how to fix it any better
than this.
I don't find it
(add-hook 'after-change-functions 'yell-at-me)
Usually after-change-functions are only added buffer-locally, like this:
(add-hook 'after-change-functions 'yell-at-me nil t)
-- Stefan
___
Emacs-pretest-bug mailing list
Emacs-pretest-bug@gnu.org
I get the same bugged behavior (in Emacs -q) when these are both `t':
pop-up-frames
display-buffer-reuse-frames
In fact, it is in such a setup that I first discovered the bug.
Could you post a detailed recipe, so I can try and reproduce
the problem?
A detailed recipe
If I do (setq special-display-regexps '([ ]?[*][^*]+[*])), then when I hit
`d' in the debugger, the debugger frame iconifies.
Doesn't it de-iconify right after (thus flashing)? That's very odd.
No; it does not deiconify.
Oh, I think I know what it is: that's because of Richard's new
With parse-sexp-ignore-comments t and point in between ( in
(setq foo (;))
forward-sexp gets me
forward-sexp: Scan error: Unbalanced parentheses.
Obviously, this is because scan-lists finds the semicolon and does not
check whether it's inside a string. Could someone please add the
I'm saying that in the case of `q' or `c', I don't want the keep
displaying the frame, instead I want it iconified.
In the case of `c', I definitely want to keep displaying the debugger. Why
would you want it to disappear? Using `c' doesn't mean you're done with the
debugger. I can
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
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
1 - 100 of 725 matches
Mail list logo
