Why didn't you try the very first solution I proposed? You have to
activate font-lock-mode _after_ setting the defaults, like this
# Local Variables:
# font-lock-defaults: ((^\\s-*:0 ##+))
# mode: font-lock
# End:
I had not understood this suggestion. As soon as I build emacs 22 I'll
try again
At http://directory.fsf.org/GNU/emacs.html a link is provided to the
source tarball of Emacs 21.4a, rather than 22.1.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
I had this in my local variables section:
mode: font-lock
font-lock-keywords: (^\\S-.*:$)
which worked in Emacs 21, but does not work any more in Emacs 22. I
solved the problem by writing instead:
mode: font-lock
font-lock-defaults: ((^\\S-.*:$))
I must say that I don't know why
Should this fix be installed in Emacs 22.1?
Or is it safer for us to leave that bug unfixed?
I have no idea of the reasons or the implications of this change, nor if
the correct behaviour was the previous or the current one.
Only thing I say, if it is left as it is, maybe it should be mentioned
I had this in my local variables section:
mode: font-lock
font-lock-keywords: (^\\S-.*:$)
which worked in Emacs 21, but does not work any more in Emacs 22. I
solved the problem by writing instead:
mode: font-lock
font-lock-defaults: ((^\\S-.*:$))
I must say that I don't know why
I forgot to answer this previously, sorry. I summarise.
I had this in my local variables section:
mode: font-lock
font-lock-keywords: (^\\S-.*:$)
which worked in Emacs 21, but does not work any more in Emacs 22. I
solved the problem by writing instead:
mode: font-lock
font-lock-defaults:
In my local Emacs hacks, I've fixed the inconsistency the other
way: revert doesn't throw away undo info any more.
That seems bizarre, but I guess we should consider it.
However, Emacs 22.0.990 still throws away undo when reverting dired
buffers :-(
This is a change with respect to
From textmodes/sgml-mode.el:
If you like upcased tags, put (setq sgml-transformation-function 'upcase)
in your `.emacs' file.
To reproduce the problem:
emacs -Q
C-x C-f a.html RET
M-x set-variable RET sgml-transformation-function RET upcase RET
C-c C-t small
This problem was due to a very stupid bug of mine, sorry. It should
be fixed now, please try again.
Tried, and the problem has disappeared for the test cases I tried.
Thanks.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
- download http://fly.isti.cnr.it/tmp/base54.mbox (I am appending it to
Should have been http://fly.isti.cnr.it/tmp/base64.mbox, sorry.
the end of this mail, but I am not sure it will arrive intact)
Here it is, sorry again:
===File ~/www/tmp/base64.mbox===
From
Does this patch make it work in both cases?
Yes, this one works in both cases.
*** mailabbrev.el 21 Jan 2007 01:36:15 -0500 1.82
--- mailabbrev.el 04 May 2007 22:59:43 -0400
***
*** 494,499
--- 494,502
;; the usual syntax table.
+ ;; Do let Ctl and Meta chars expand if they try.
+ (not (event-modifiers last-command-char))
+ (equal this-command 'self-insert)
Why check (not (event-modifiers last-command-char)), then?
Maybe it isn't necessary
Does this fix it?
*** mailabbrev.el 21 Jan 2007 01:36:15 -0500 1.82
--- mailabbrev.el 28 Apr 2007 21:05:27 -0400
***
*** 494,499
--- 494,501
;; the usual syntax table.
(or (and (integerp last-command-char)
+
It used to work in dired buffers.
That seems incredible. Deleting the whole text of a directory listing
and reading it again is an operation that cannot preserve undo data.
Yet, this is easy to reproduce. Invoke emacs 21 with -q, then
C-x d /tmp RET
M-! touch 00a RET
g -- Now yu should
Apparently mail-abbrev-end-of-buffer does nothing special: it jumps to
the end of buffer but does not expand the abbreviation.
The code tries to expand:
...
Why doesn't it work for you?
The problem is in mailabbrev.el, in sendmail-pre-abbrev-expand-hook,
where it does:
;; If the
it was useful when I updated a dired buffer with 'g' without looking at
it first, and wanted to look at its old status. Very handy in some
situations.
Handy if you know what you are doing, but potentially very confusing
and dangerous for the average/naive user.
The user had to toggle the
Apparently mail-abbrev-end-of-buffer does nothing special: it jumps to
the end of buffer but does not expand the abbreviation. On the other
hand, mail-abbrev-next-line works normally.
In GNU Emacs 22.0.96.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.8.20)
of 2007-04-02 on tucano.isti.cnr.it
Apparently, Emacs 22 does not allow to undo in dired buffers.
This is a pity, because it sometimes occurred to me to revert a dired
buffer (using 'g') and then wanting to see the differences using undo.
If this change is the result of a meditated choice, maybe it has some
reason. But if it has
I have a ~/.procmailrc file that has these lines at the end:
# Local Variables:
# mode: indented-text
# fill-column: 95
# mode: font-lock
# font-lock-keywords: (^\\s-*:0 ##+)
# End:
Now, when desktop.el loads it, it asks if I want to apply the
font-lock-keywords customisation, because it is
# font-lock-keywords : (^\\s-*:0 ##+)
# End:
Now, when desktop.el loads it, it asks if I want to apply the
font-lock-keywords customisation, because it is risky (is it?).
The question is asked by `hack-local-variables-confirm'.
Fine.
I
answer y, but I get the message:
Toggling
Calling C-u M-x locate RET gives no results, whatever the command line.
A bug was apparently introduced in locate.el, but I did not check when
and why. I found the problem in 22.0.96, but, by looking at the source,
it is still there in 22.0.98.
Here is a patch and Changelog entry:
2007-04-20
editfns.c: In function 'Fuser_uid':
editfns.c:1317: warning: comparison is always false due to limited range of
data type
process.c: In function 'Fdelete_process':
process.c:820: warning: comparison is always false due to limited range of
data type
I think I fixed these now in the CVS,
If the argument i is of type int (32bit), then the compiler is sufficiently
clever to infer that the comparisons will always return the same value
(even though we cast that value to EMACS_INT (64bit) in between).
Is it really that smart?
Apparently, yes. But also enough stupid that it
Will it also be that smart if we do some
arithmetics, like `(EMACS_INT)i + 0L' or `(EMACS_INT)i*1L'?
Will try that and see if it is useful to make the warning go away.
No, it changes nothing: the compiler is too clever, but not enough :-)
But, rereading it:
#define
But since this warning is about something which is not itself a bug, either
gcc provides a way to annotate the code to indicate that this is not a bug
(like the use of double-parens to turn off the warning about assignment in
an `if'), or there's not much we can do about it (other than try to work
/home/pot/gnu/emacs-22.0.91/src/prefix-args.c: In function 'main':
/home/pot/gnu/emacs-22.0.91/src/prefix-args.c:64: warning: incompatible
implicit declaration of built-in function 'exit'
/home/pot/gnu/emacs-22.0.91/src/prefix-args.c:73: warning: incompatible
implicit declaration of
process.c: In function 'Fsignal_process':
process.c:6114: warning: cast from pointer to integer of different size
I think this is a real bug. Please try this patch:
2006-12-09 Eli Zaretskii [EMAIL PROTECTED]
* process.c (Fsignal_process): Doc fix. Use XFLOAT_DATA to
extract
I get these warnings during compilation on x86_64-unknown-linux-gnu with
Debian testing with gcc (GCC) 4.1.2 20061028 (prerelease) (Debian 4.1.1-19)
[...]
gcc -c -D_BSD_SOURCE -Demacs -DHAVE_CONFIG_H -I.
-I/home/pot/gnu/emacs-22.0.91/src -D_BSD_SOURCE -g -O2 -Wno-pointer-sign
I get these warnings during compilation on x86_64-unknown-linux-gnu with
Debian testing with gcc (GCC) 4.1.2 20061028 (prerelease) (Debian 4.1.1-19)
I identified the reason for the first one and posted it on emacs-devel,
where I am going to follow up the answer I got. I plan to consider the
29 matches
Mail list logo
