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,
applications.
In the event that my mailer or yours trashes the character encoding of the
patch, I’ve made a bzip2’d version of the full file available at
http://www.parhasard.net/ipa-20070114.el.bz2 .
leim/ChangeLog addition:
2007-01-14 Aidan Kehoe [EMAIL PROTECTED]
* quail/ipa.el
of the entire file available under
http://www.parhasard.net/morse-20070114.el.bz2 .
lisp/ChangeLog addition:
2007-01-14 Aidan Kehoe [EMAIL PROTECTED]
* play/morse.el:
* play/morse.el (require):
* play/morse.el (morse-code): Removed.
* play/morse.el (active-morse-code
Stefan Monnier [EMAIL PROTECTED] writes:
shell-file-name is /bin/bash.
That's the bug. `shell-file-name' should be /bin/sh.
Really? The doc says:
shell-file-name is a variable defined in `C source code'.
Its value is /bin/bash
Documentation:
*File name to load inferior shells
I think I fixed these now in the CVS, please take a look.
It's just a bad workaround which may work for now. The warning may come
back with additional optimizations in gcc (either in the future or maybe
even already now with a higher optimization level).
The problem is gcc's, really.
Mathias Dahl wrote:
Yes, we discussed that before. However, I feel that is a clean up
with should do after the release (Lennart won't agree with me
though... :)
I would say that it is not clean up. It is fixing real bugs.
___
emacs-pretest-bug
From: Stefan Monnier [EMAIL PROTECTED]
To: Francis Wright [EMAIL PROTECTED]
Cc: emacs-pretest-bug@gnu.org
Sent: Sunday, January 07, 2007 7:32 PM
Subject: Re: [:upper:] inconsistency
I would expect the regexp [[:upper:]] to behave the same as [A-Z] (in
English text). However, by default
From: Stefan Monnier [EMAIL PROTECTED]
To: Francis Wright [EMAIL PROTECTED]
Cc: emacs-pretest-bug@gnu.org
Sent: Sunday, January 07, 2007 7:32 PM
Subject: Re: [:upper:] inconsistency
I would expect the regexp [[:upper:]] to behave the same as [A-Z] (in
English text). However, by default
Date: Sun, 14 Jan 2007 12:35:04 +0100
From: Francesco Potorti` [EMAIL PROTECTED]
Cc: emacs-pretest-bug@gnu.org
I think I fixed these now in the CVS, please take a look.
Yes, the warnings have disappeared.
The workaround is to define a variable of type EMACS_INT, assign to it
the value
Date: Sun, 14 Jan 2007 14:59:58 +0100
From: Aidan Kehoe [EMAIL PROTECTED]
this patch addes support for the more-widely used ones to it, with
two new input methods, kirshenbaum-ipa and x-sampa-ipa, following the names
of the two conventions.
Thanks.
It also moves the file encoding to
shell-file-name is /bin/bash.
That's the bug. `shell-file-name' should be /bin/sh.
Really? The doc says:
shell-file-name is a variable defined in `C source code'.
Its value is /bin/bash
Documentation:
*File name to load inferior shells from.
Initialized from the SHELL
Cc: Francesco Potorti` [EMAIL PROTECTED], emacs-pretest-bug@gnu.org
From: Stefan Monnier [EMAIL PROTECTED]
Date: Sun, 14 Jan 2007 09:53:07 -0500
I think I fixed these now in the CVS, please take a look.
It's just a bad workaround
What's bad about it?
The warning may come back with
It means that somewhere you (or someone else) gave Emacs a font name that
does
not exist on your system.
Emacs should not die just because someone specifies a nonexistent font
name. It should detect that error, report it cleanly to the user, and
carry on.
If someone can figure out
Ar an ceathrú lá déag de mí Eanair, scríobh Eli Zaretskii:
It also moves the file encoding to UTF-8, since Kirshenbaum and X-SAMPA
require more character codes than are provided by the Mule IPA
character set, and since UTF-8 is more compatible with other
applications.
IMO, the
When calling ispell, get the following error:
ispell-check-version: /Applications/emacs/Emacs.app/Contents/MacOS/
bin/aspell exited with signal Trace/BPT trap
In GNU Emacs 22.0.92.1 (powerpc-apple-darwin8.8.0, Carbon Version 1.6.0)
of 2007-01-06 on g5.tokyo.stp.isas.jaxa.jp
X server
(This is a resend from my report one month ago to the CC Mode mailing
list, which I did receive no reaction on.)
Hello!
I am using GNU Emacs 22.0.92.1. The following applies to CC Mode shipped
with that version as well as to CC Mode 5.31.3.
In my .emacs I have set '(c-offsets-alist (quote
Jan Djärv [EMAIL PROTECTED] writes:
By using sigblock/sigunblock we make sure that counter isn't
touched, so it fixes this particular case. However, why the counter
gets the wrong value is still not known.
Can anyone even reproduce the bug other than me?
If not, I'm more than happy to run
It is too late to install such changes before the coming release.
Could you remind us after the release?
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
I recall fixing something like this a few weeks ago.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
I think the following patch should be applied to ispell.el (but I don't
use polish).
What bug is this trying to fix?
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Thanks for the patch. However, it doesn't fix the problem. The following
version of the function that you patched does seem to work. I have moved
the `not' outside the `or' at the start of your patch.
Yes, there was some funny mixup in not/or/and.
enough to suggest a fix. The sexpr
I think I fixed these now in the CVS, please take a look.
It's just a bad workaround
What's bad about it?
Makes the code heavier. But it's pretty minor, indeed. It's definitely the
best workaround we have seen so far.
The warning may come back with additional optimizations in gcc
Are you
From: Todd Wylie [EMAIL PROTECTED]
Date: Sat, 13 Jan 2007 22:01:16 -0600
When calling ispell, get the following error:
ispell-check-version: /Applications/emacs/Emacs.app/Contents/MacOS/
bin/aspell exited with signal Trace/BPT trap
That looks like a bug in aspell. Does it work from the
Ar an ceathrú lá déag de mí Eanair, scríobh Richard Stallman:
It is too late to install such changes before the coming release.
Could you remind us after the release?
I can’t guarantee I’ll remember, but I’ll try, sure.
--
When I was in the scouts, the leader told me to pitch a tent. I
I recall fixing something like this a few weeks ago.
Yes, I just picked up a build from Dec 30, and it is fixed in that build.
Thx.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
I think the following patch should be applied to ispell.el (but I don't
use polish).
What bug is this trying to fix?
In English you use the regexp ['] to match any ' embedded in a word
like don't. In Polish . would match _any_ character embedded in a
word. Simply noticed by
26 matches
Mail list logo
