On Sun, 10 Dec 2006 20:06:23 -0500, Richard Stallman [EMAIL PROTECTED]
said:
Please clearly state exactly what input events are needed to make
the problem happen.
It seems like a problem that is specific to the Mac Carbon port.
Please try the following patch. If there's no problem with
BTW, in Elisp an open bracket in column zero of a string should not
confuse Emacs. Yet you highlight it with `font-lock-warning-face'.
Indeed, it *shouldn't*, but it does confuse Emacs, which is why it's
highlighted ;-(. We should fix it so it doesn't confuse Emacs any more (and
doesn't
When starting with
emacs -Q -fs
the lower part of Emacs may get hidden behind the MS Windows task bar.
This happens because Emacs window is not really maximized. Unfortunately
this means that Emacs' minibuffer is not visible.
In GNU Emacs 22.0.91.1 (i386-mingw-nt5.1.2600)
of 2006-12-10
X
Nick Roberts wrote:
PS Fun times ahead in 3 weeks when every single file in Emacs needs
2007 adding to the Copyright years...
Doesn't this make it a bit silly then to just to do it for 2006?
I'm not just doing it for 2006. I'm clearing up the mess (IMO) that
remains several months after
On 11 Dec 2006, at 08:01, YAMAMOTO Mitsuharu wrote:
On Sun, 10 Dec 2006 20:06:23 -0500, Richard Stallman
[EMAIL PROTECTED] said:
Please clearly state exactly what input events are needed to make
the problem happen.
It seems like a problem that is specific to the Mac Carbon port.
Please
Using this 2 line .emacs file:
(require 'ido)
(ido-mode t)
and with hundreds of files in /usr/bin/, including /usr/bin/gnuplot,
typing:
C-x C-f / u s r / b i n / g n u p l o ?
shows me a message There are no possible completions of what you have
typed, but hitting SPC or TAB goes on to
/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
On Fri, 08 Dec 2006 08:05:56 +0100 Jan Djärv [EMAIL PROTECTED] wrote:
Stephen Berman skrev:
Well, now I can get GTK-Emacs to segfault again :-). I noticed that
the desktop fonts didn't look as sharp as they normally do (it took me
a while to notice this, probably because the fonts in Emacs
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
Chris Moore [EMAIL PROTECTED] writes:
Using this 2 line .emacs file:
(require 'ido)
(ido-mode t)
and with hundreds of files in /usr/bin/, including /usr/bin/gnuplot,
typing:
C-x C-f / u s r / b i n / g n u p l o ?
shows me a message There are no possible completions of what you
* [2006.12.11 14:37 +0100] Kim F. Storm wrote:
C-x C-f / u s r / b i n / g n u p l o ?
shows me a message There are no possible completions of what you have
typed, but hitting SPC or TAB goes on to complete it to gnuplot, as
expected. Which typing
On 12/11/06, Leo [EMAIL PROTECTED] wrote:
ido-max-directory-size default to 3 and the number of files in
/usr/bin/ on my system is 2067.
Documentation:
*Maximum size (in bytes) for directories to use ido completion.
If you enter a directory with a size larger than this size, ido will
not
However, I recently found this backup file:
./cur/1165087471.P20227Q7.chrislap:2,S/1164450633.P2139Q0M622761.chrislap:2,S.~1~
It is a backup of this file:
./cur/1164450633.P2139Q0M622761.chrislap:2,S
For some reason it was created in:
* [2006.12.11 15:47 +0100] Juanma Barranquero wrote:
^^
On 12/11/06, Leo [EMAIL PROTECTED] wrote:
ido-max-directory-size default to 3 and the number of files in
/usr/bin/ on my system is 2067.
Documentation:
*Maximum size (in bytes) for
Chris Moore [EMAIL PROTECTED] writes:
[EMAIL PROTECTED] (Kim F. Storm) writes:
Look at ido-max-directory-size.
In this case C-a is your friend.
The bug is that the message says:
There are no possible completions of what you have typed
when in fact there are possible completions of
Eli Zaretskii wrote:
Date: Fri, 08 Dec 2006 02:18:20 +0100
From: Lennart Borgman [EMAIL PROTECTED]
Cc: Deutsch, Will [EMAIL PROTECTED], emacs-pretest-bug@gnu.org
On the other hand we might be receiving bug reports just because there
are more users if we supply a prebuildt binary on MS Windows.
Eli Zaretskii [EMAIL PROTECTED] writes:
There's no cus-load.el in the pretest tarball; I think that's a bug
that causes this. A normal build does not regenerate cus-load.el,
only a bootstrap does.
That's strange. Maybe there was a glitch when I rolled the last
pretest tarball; make-dist
Hello.
This is so far inside fontconfig and the theme engine that you use, so I
suspect nothing Emacs does can help. It seem to crash on
/usr/X11R6/lib/X11/fonts/misc/cu12.pcf.gz, have you tried to remove that file?
It may be a bad font (I don't know what cu12.pcf is, Courier 12?).
An idea why
Chris == Chris Moore [EMAIL PROTECTED] writes:
Chris
Chris Klaus Zeitler [EMAIL PROTECTED] writes:
When I change the frame to 81 columns (the tab in the long line is now
wrapped after 1 char), clicking on the '7' will set the cursor to '6'.
In GNU Emacs 22.0.50.14
Cc: emacs-pretest-bug@gnu.org
From: Chong Yidong [EMAIL PROTECTED]
Date: Mon, 11 Dec 2006 14:10:09 -0500
Eli Zaretskii [EMAIL PROTECTED] writes:
There's no cus-load.el in the pretest tarball; I think that's a bug
that causes this. A normal build does not regenerate cus-load.el,
only
Date: Mon, 11 Dec 2006 13:43:17 +0100
From: Francesco Potorti` [EMAIL PROTECTED]
Cc: emacs-pretest-bug@gnu.org
The reason why those warnings are there is that a comparison is made
between an int (32 bits) or a short (16 bits) and a constant long (64 bits).
Are you talking about the
Date: Mon, 11 Dec 2006 22:29:59 +0200
From: Eli Zaretskii [EMAIL PROTECTED]
Cc: emacs-pretest-bug@gnu.org
The only glitch that can explain this is if cus-load.el was not
generated in the source tree from which you ran make-dist.
Either not generated or inadvertently deleted.
Eli Zaretskii wrote:
Date: Thu, 7 Dec 2006 23:55:58 -0800
From: Deutsch, Will [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED],
[EMAIL PROTECTED],
emacs-pretest-bug@gnu.org
I was specifically asked to provide the / vs \ output of Dir.
Sorry, I missed that.
Lennart, can you tell
On Mon, 11 Dec 2006 20:35:13 +0100 Jan Djärv [EMAIL PROTECTED] wrote:
Hello.
This is so far inside fontconfig and the theme engine that you use,
so I suspect nothing Emacs does can help. It seem to crash on
/usr/X11R6/lib/X11/fonts/misc/cu12.pcf.gz, have you tried to remove
that file? It
Are you talking about the comparison in FIXNUM_OVERFLOW_P? If so,
where's the 32-bit int and the 64-bit long in that macro? I must be
missing something, because what I see there is a comparison between
two values which are both cast to EMACS_INT, which makes them both of
type long.
If the
Previously in Emacs 22, as well as in previous releases, , repeating
grep in the *grep* buffer would put you at the top of the buffer. This
was true at least as late as a build from 2006-07-19.
Now, it puts you at the end of the buffer, so you must do M- to get
back to the beginning. Quite
Hi,
I noticed that Japanese text cannot be displayed in the menu bar.
I use the LUCID menu bar, not the GTK version, and I don't have
X resources. You will be able to reproduce this by starting
Emacs with the -Q option and evaluating the following form:
(let ((japanese (decode-coding-string
There's no cus-load.el in the pretest tarball; I think that's a bug
that causes this. A normal build does not regenerate cus-load.el,
only a bootstrap does.
I think you figured it out. We need to put cus-load.el in the
distribution.
Can someone please do so, then ack?
This seems to be by design however, since read-file-name-internal only
applies the predicate when returning the full list of completions; for
normal completion, file-name-completion is called and the predicate
remains completely unused. Perhaps file-name-completion should
get
Date: Mon, 11 Dec 2006 22:52:59 +0100
From: Lennart Borgman [EMAIL PROTECTED]
CC: Deutsch, Will [EMAIL PROTECTED], [EMAIL PROTECTED],
emacs-pretest-bug@gnu.org
Lennart, can you tell why you asked for that, and what does it have to
do with the original problem?
(Did I explain why
Cc: Francesco Potorti` [EMAIL PROTECTED], emacs-pretest-bug@gnu.org
From: Stefan Monnier [EMAIL PROTECTED]
Date: Mon, 11 Dec 2006 17:52:44 -0500
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
Date: Tue, 12 Dec 2006 00:09:00 +0100
From: Lennart Borgman [EMAIL PROTECTED]
It turned out that the test below for execute access failed. That seems
strange since indeed runemacs.exe can be executed. Is that perhaps a bug
in MinGW or in w32? Or am I misunderstanding something? Where
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? Will it also be that smart if we do some
arithmetics,
34 matches
Mail list logo
