Re: mouse click into window doesn't always select frame
> 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 this for a
few days, I'll install it.
YAMAMOTO Mitsuharu
[EMAIL PROTECTED]
Index: src/macterm.c
===
RCS file: /cvsroot/emacs/emacs/src/macterm.c,v
retrieving revision 1.198
diff -c -p -r1.198 macterm.c
*** src/macterm.c 10 Dec 2006 23:16:11 - 1.198
--- src/macterm.c 11 Dec 2006 07:54:05 -
*** XTread_socket (sd, expected, hold_quit)
*** 10398,10410
break;
case inContent:
! if (
! #if TARGET_API_MAC_CARBON
! FrontNonFloatingWindow ()
! #else
! FrontWindow ()
! #endif
! != window_ptr)
SelectWindow (window_ptr);
else
{
--- 10398,10404
break;
case inContent:
! if (mac_window_to_frame (window_ptr) != dpyinfo->x_focus_frame)
SelectWindow (window_ptr);
else
{
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Mysterious fontification/C++ context issue
>>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 get highlighted either).
Due to the fact that "\\s(" is hardwired in `font-lock-compile-keywords'
and can't be set individually by a major mode. A minor issue showing
that it's not entirely trivial to give a simple recipe fitting all major
modes.
What I meant is "stay away from putting an open paren in column zero
unless it starts a defun" in any programming mode where "open paren" is
what the syntax table says it is. It's one constraint for the user,
easy to explain, understand, and implement, difficult to defend, tho.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
-fs hides part of Emacs window behind task bar on w32
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 server distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4) --cflags -Id:/g/include' ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: bad copyright years
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 the copyright statements in general were supposedly all checked. Adding 2007 when the time comes ought to be almost totally automatic, as you say. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: mouse click into window doesn't always select frame
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 try the following patch. If there's no problem with this for a few days, I'll install it. Thanks, I'll have a look at this and report back. D ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
ido.el reports possible completions wrongly
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 complete it to gnuplot, as
expected. Which typing the "gnuplo" part, I see "[Too big]" in the
minibuffer after the cursor.
Note also that immediately before typing the "g" in the above input,
the minibuffer displays:
Find file: /usr/bin/{bin/ | sbin/}
suggesting that /usr/bin/ contains subdirectories called 'bin' and
'sbin' (which it doesn't). Typing the '/' after 'bin' should have
made ido move on to the contents of the /usr/bin/ directory, but since
it's a big directory, it doesn't.
In GNU Emacs 22.0.91.28 (i686-pc-linux-gnu, GTK+ Version 2.8.20)
of 2006-12-11 on chrislap
X server distributor `The X.Org Foundation', version 11.0.70101000
configured using `configure '--with-gtk' '--prefix' '/usr/local/emacs22'
'--with-xpm' '--with-jpeg' '--with-png' '--with-gif''
Important settings:
value of $LC_ALL: en_GB.UTF-8
value of $LC_COLLATE: nil
value of $LC_CTYPE: nil
value of $LC_MESSAGES: nil
value of $LC_MONETARY: nil
value of $LC_NUMERIC: nil
value of $LC_TIME: nil
value of $LANG: en_GB.UTF-8
locale-coding-system: utf-8
default-enable-multibyte-characters: t
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: warnings compiling Emacs 22 on amd64
>> /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 built-in function 'exit' > >Do these warnings go away if you #include in prefix-args.c? Yes, they go away. I had not tried that myself because apparently prefix-args.c was written to be compilable on everything, even when stdlib.h is not there, but times are changing, so I think your change is the way to go. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: warnings compiling Emacs 22 on amd64
>> 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 the process ID from a Lisp float. The warning went away, and the compilation proceeded successfully. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: GTK build crashes under X
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 are always >> not so sharp :-), so I ran fc-cache, exited KDE and logged on again. >> Now my desktop fonts are back to their previous sharpness, but >> Emacs-GTK segfaults again with the standard invocation (but I can >> start it by setting LD_LIBRARY_PATH to /usr/local/lib). So if someone >> is able to advise me how to debug this, I can try to do it. >> > > It is hard if Emacs doesn't fail with the debug-compiled fontconfig. > Does wxGTK install fonts? No, AFAICT (and a wxwidget developer told me it does not alter pango or fontconfig). >The cache handling seems to have some bug > in it. As it only fails sometimes it might be that the code that > builds or reads the cache have some uninitialized variable that gets > random garbage. Sometimes that garbage is OK, sometimes it isn't. This may well be the case, as I'm getting rather unpredictable behavior. The next time I started GTK-Emacs (without setting LD_LIBRARY_PATH to /usr/local/lib) after writing the above, it came up fine, no segfault. Then I updated the Nvidia-driver for my graphic card, and the next time I booted and started Emacs (last night), the GTK build segfaulted again. But this time, it also segfaulted even after setting LD_LIBRARY_PATH to /usr/local/lib, i.e., I could not started the GTK build at all (neither the CVS nor first pretest builds; the Lucid build was as usual unaffected). Fortunately, this time the gdb full backtrace (appended to the end of this post) includes values from the fontconfig source, though lots are optimized out; still perhaps you can get some useful information out of it. BTW, notice that this backtrace is quite different from the one I originally sent (and had gotten on every previous segfault). A further datapoint: When I booted SUSE 10.1 this morning, X started and the kdm login screen came up, but I could not start any desktop (I tried KDE several times, Gnome, and FVWM), restarting X didn't help. Then I noticed that ~/.fonts.cache-2 was again very large, ~1.8MB, and the timestamp was from just after booting. I deleted this file, ran fc-cache as root, went back to the kdm screen, and could start KDE as usual. I then invoked Emacs-GTK, and it started without a problem! > If you rebuild the cache several times with the same fontconfig, are > the ~/.fonts.cache-2 then identical? And are they different if you > rebuild with the fontconfig you compiled? After running fc-cache again this morning, ~/.fonts.cache-2 was not recreated. This was with /usr/local/bin/fc-cache, i.e., the one I compiled. I haven't tried again with /usr/bin/fc-cache, as I'm a little afraid of the consequences, given what I described above. If (or when) I have problems again with Emacs starting, I'll try to do both and compare. >Does any other Gnome/GTK > application fail when Emacs fails or is it just Emacs? I've only had problems with Emacs. I mostly use KDE, but aside from Emacs, no other GTK application I use (mostly Firefox and several games, Eclipse, Gimp) has segfaulted AFAICR, at least not the way Emacs has been doing, right on startup, since I first installed wxGTK. (There are at least two other issues I've had with GTK-Emacs that I've not had with any other GTK application, but they have to do specifically with KDE and not with wxGTK or fonts, so I assume they are not related to this problem, except (and that in itself is perhaps significant) for being restricted to Emacs.) Steve Berman ___ Here's the backtrace from last night's segfault: [EMAIL PROTECTED]:/users/steve/cvsroot/emacs/src> gdb emacs GNU gdb 6.4 Copyright 2005 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i586-suse-linux"...Using host libthread_db library "/lib/libthread_db.so.1". DISPLAY = :0 TERM = xterm Breakpoint 1 at 0x80f2e26: file emacs.c, line 449. Breakpoint 2 at 0x810bd66: file sysdep.c, line 1385. (gdb) r Starting program: /users/steve/cvsroot/emacs/src/emacs -geometry 80x40+0+0 [Thread debugging using libthread_db enabled] [New Thread -1220639056 (LWP 6024)] [Switching to Thread -1220639056 (LWP 6024)] Breakpoint 3 at 0x80c82e6: file xterm.c, line 7833. Program received signal SIGSEGV, Segmentation fault. 0xb79c3e24 in FcPatternPosition (p=0xb68f9004, object=) at fcint.h:828 828 return a - b; (gdb) bt full #0 0xb79c3e24 i
Re: warnings compiling Emacs 22 on amd64
>> 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 >> editfns.c >> editfns.c: In function 'Fuser_uid': >> editfns.c:1317: warning: comparison is always false due to limited range of >> data type >> editfns.c:1317: warning: comparison is always false due to limited range of >> data type >> editfns.c: In function 'Fuser_real_uid': >> editfns.c:1325: warning: comparison is always false due to limited range of >> data type >> editfns.c:1325: warning: comparison is always false due to limited range of >> data type > >These and other similar warnings seem all to come from the use of >MOST_POSITIVE_FIXNUM and MOST_NEGATIVE_FIXNUM. Do these warnings go >away if you modify those two macros as below? > >#define MOST_NEGATIVE_FIXNUM - ((EMACS_INT) (1 << (VALBITS - 1))) >#define MOST_POSITIVE_FIXNUM ((EMACS_INT) (1 << (VALBITS - 1) - 1)) No, those definitions are wrong: on amd64, EMACS_INT is a long, so the above is wrong because 1 is an int and is shifted by more than its size. The way things are defined now, that is: #define MOST_NEGATIVE_FIXNUM- ((EMACS_INT) 1 << (VALBITS - 1)) #define MOST_POSITIVE_FIXNUM(((EMACS_INT) 1 << (VALBITS - 1)) - 1) is correct as far as I can see, because 1 is cast to long, then shifted, which yields a long. The reason why thos ewarnings are there is that a comparison is made between an int (32 bits) or a short (16 bits) and a constant long (64 bits). Such a comparison is useless, because the compiler knows that the constant long is always bigger than the int, due to its size. I tried to avoid the comparison by changing the FIXNUM_OVERFLOW_P macro like this: #define FIXNUM_OVERFLOW_P(i) \ (sizeof(i) >= sizeof(EMACS_INT) \ && ((EMACS_INT)(i) > MOST_POSITIVE_FIXNUM \ || (EMACS_INT)(i) < MOST_NEGATIVE_FIXNUM)) that is, by adding a test on sizeof at the beginning. However, this has no effect and the following warnings are always there: 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 editfns.c editfns.c: In function 'Fuser_uid': editfns.c:1317: warning: comparison is always false due to limited range of data type editfns.c:1317: warning: comparison is always false due to limited range of data type editfns.c: In function 'Fuser_real_uid': editfns.c:1325: warning: comparison is always false due to limited range of data type editfns.c:1325: warning: comparison is always false due to limited range of data type 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 fns.c fns.c: In function 'maybe_resize_hash_table': fns.c:4684: warning: comparison is always false due to limited range of data type 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 process.c process.c: In function 'Fdelete_process': process.c:820: warning: comparison is always false due to limited range of data type process.c:820: warning: comparison is always false due to limited range of data type process.c:830: warning: comparison is always false due to limited range of data type process.c:830: warning: comparison is always false due to limited range of data type process.c: In function 'Fprocess_id': process.c:917: warning: comparison is always false due to limited range of data type process.c:917: warning: comparison is always false due to limited range of data type process.c: In function 'sigchld_handler': process.c:6441: warning: comparison is always false due to limited range of data type process.c:6441: warning: comparison is always false due to limited range of data type Doing like this: #define FIXNUM_OVERFLOW_P(i) \ ((sizeof(i) < sizeof(EMACS_INT)) ? 0 \ : ((EMACS_INT)(i) > MOST_POSITIVE_FIXNUM \ || (EMACS_INT)(i) < MOST_NEGATIVE_FIXNUM)) still changes nothing. Apparently the compiler runs the second test even if the first one fails, and so issues a warning. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: ido.el reports possible completions wrongly
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 have
> typed", but hitting SPC or TAB goes on to complete it to gnuplot, as
> expected. Which typing the "gnuplo" part, I see "[Too big]" in the
> minibuffer after the cursor.
Look at ido-max-directory-size.
In this case C-a is your friend.
>
> Note also that immediately before typing the "g" in the above input,
> the minibuffer displays:
>
> Find file: /usr/bin/{bin/ | sbin/}
>
> suggesting that /usr/bin/ contains subdirectories called 'bin' and
> 'sbin' (which it doesn't).
No, it suggests that /usr contains two directories 'bin' and 'sbin' that
match what you wrote.
> Typing the '/' after 'bin' should have
> made ido move on to the contents of the /usr/bin/ directory, but since
> it's a big directory, it doesn't.
No, it doesn't go to bin/ since there is another possible completion.
You can modify this by setting ido-enter-matching-directory to 'first.
So no errors here :-)
--
Kim F. Storm <[EMAIL PROTECTED]> http://www.cua.dk
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: ido.el reports possible completions wrongly
* [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 the "gnuplo" part, I see "[Too big]" in the >> minibuffer after the cursor. > > Look at ido-max-directory-size. > In this case C-a is your friend. ido-max-directory-size default to 3 and the number of files in /usr/bin/ on my system is 2067. But I am still seeing this problem. -- Leo (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: ido.el reports possible completions wrongly
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 provide the normal completion. To show the completions, use C-a. Note the "size (in bytes)". /L/e/k/t/u ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [Patch] build cvs emacs for x86_64-sun-solaris10
Thanks for making that platform work. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: backup-directory-alist not always honoured
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: ./cur/1165087471.P20227Q7.chrislap:2,S/ instead of in ./cur/Backup/ as I would expect. I looked at the code and I can't see any way that this failure could happen. I am stumped. How about if you modify the function make-backup-file-name-1 to adde data showing its argument and value at the end of a particular file. Then, if the bug happens again, you can check that file and see what make-backup-file-name-1 did on that occasion. At least that way we will find out if the bug is inside that function. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: ido.el reports possible completions wrongly
* [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 directories to use ido completion. > If you enter a directory with a size larger than this size, ido will > not provide the normal completion. To show the completions, use C-a. > > Note the "size (in bytes)". > >/L/e/k/t/u I realized that after my post :-) -- Leo (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: ido.el reports possible completions wrongly
[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 what I have typed. Better behaviour would be to either modify the message to indicate that it isn't known whether there are possible completions because we didn't look yet, or better, to look (like what happens when SPC or TAB is pressed). > No, it doesn't go to bin/ since there is another possible completion. OK, accepted. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: backup-directory-alist not always honoured
Richard Stallman <[EMAIL PROTECTED]> writes: > I looked at the code and I can't see any way that this failure could > happen. I am stumped. I believe that what happened was that the Backup/ directory was created as it should have been, and then the dovecot mail server program renamed it later. I've not had this problem anywhere other than when editing files inside ~/Maildir/ , which is the dovecot server's domain. I think we can safely ignore this 'bug'. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Mysterious fontification/C++ context issue
>>> 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 get highlighted either).
> Due to the fact that "\\s(" is hardwired in `font-lock-compile-keywords'
> and can't be set individually by a major mode.
It's only hardwired in font-lock-compile-keywords for the (good) reason that
it's hardwired in beginning-of-defun. Of course, if we fix
beginning-of-defun, we should adjust font-lock-compile-keywords accordingly.
The problem really fundamentally lies in beginning-of-defun.
`font-lock-compile-keywords' only reflects it.
Stefan
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: ido.el reports possible completions wrongly
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 what I have typed. I just noticed also, that if I immediately type a 2nd '?': C-x C-f / u s r / b i n / g n u p l o ? ? then I see a giant list of 'possible completions': Click on a completion to select it. In this buffer, type RET to select the completion near point. Possible completions are: ./ ../ 411toppm 7z 7za 7zr 822-date AbiWord-2.4 This must be a bug, right? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: emacsclient and emacsclientw don't work in Windows Vista x64 RTM
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. It might be more important. I have no problems with having a precompiled Windows binary distro as part of the pretest, as long as it is a straight compilation of the pretest sources without any extra quirks. If you are willing to do this job, please talk to Chong Yidong and coordinate your uploads to alpha.gnu.org. I changed my routines just a little bit so I now upload also a zip file with nothing but precompiled Windows binaries of Emacs. However this is straight from the CVS, not the pretest tar balls. I see no big problem with that however. The zip file is about 50% bigger than the installer that includes both Emacs and EmacsW32. I have a new computer and better bandwidth so it is however not a problem any more. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Customize: New Options
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 seems to copy in cus-load OK. I'll keep an eye on this for the next prerelease. Thanks. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: GTK build crashes under X
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 Emacs crashes and no other may be that Emacs uses only non-AA fonts, whereas Firefox and other uses AA fonts mostly. But it is hard to tell. If removing that file doesn't help, you could try to switch to a more basic theme. But all this is just shots in the dark, I'm afraid. Jan D. Stephen Berman skrev: > 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 are always >>> not so sharp :-), so I ran fc-cache, exited KDE and logged on again. >>> Now my desktop fonts are back to their previous sharpness, but >>> Emacs-GTK segfaults again with the standard invocation (but I can >>> start it by setting LD_LIBRARY_PATH to /usr/local/lib). So if someone >>> is able to advise me how to debug this, I can try to do it. >>> >> It is hard if Emacs doesn't fail with the debug-compiled fontconfig. >> Does wxGTK install fonts? > > No, AFAICT (and a wxwidget developer told me it does not alter pango > or fontconfig). > >>The cache handling seems to have some bug >> in it. As it only fails sometimes it might be that the code that >> builds or reads the cache have some uninitialized variable that gets >> random garbage. Sometimes that garbage is OK, sometimes it isn't. > > This may well be the case, as I'm getting rather unpredictable > behavior. The next time I started GTK-Emacs (without setting > LD_LIBRARY_PATH to /usr/local/lib) after writing the above, it came up > fine, no segfault. Then I updated the Nvidia-driver for my graphic > card, and the next time I booted and started Emacs (last night), the > GTK build segfaulted again. But this time, it also segfaulted even > after setting LD_LIBRARY_PATH to /usr/local/lib, i.e., I could not > started the GTK build at all (neither the CVS nor first pretest > builds; the Lucid build was as usual unaffected). Fortunately, this > time the gdb full backtrace (appended to the end of this post) > includes values from the fontconfig source, though lots are optimized > out; still perhaps you can get some useful information out of it. > BTW, notice that this backtrace is quite different from the one I > originally sent (and had gotten on every previous segfault). > > A further datapoint: When I booted SUSE 10.1 this morning, X started > and the kdm login screen came up, but I could not start any desktop (I > tried KDE several times, Gnome, and FVWM), restarting X didn't help. > Then I noticed that ~/.fonts.cache-2 was again very large, ~1.8MB, and > the timestamp was from just after booting. I deleted this file, ran > fc-cache as root, went back to the kdm screen, and could start KDE as > usual. I then invoked Emacs-GTK, and it started without a problem! > >> If you rebuild the cache several times with the same fontconfig, are >> the ~/.fonts.cache-2 then identical? And are they different if you >> rebuild with the fontconfig you compiled? > > After running fc-cache again this morning, ~/.fonts.cache-2 was not > recreated. This was with /usr/local/bin/fc-cache, i.e., the one I > compiled. I haven't tried again with /usr/bin/fc-cache, as I'm a > little afraid of the consequences, given what I described above. If > (or when) I have problems again with Emacs starting, I'll try to do > both and compare. > >>Does any other Gnome/GTK >> application fail when Emacs fails or is it just Emacs? > > I've only had problems with Emacs. I mostly use KDE, but aside from > Emacs, no other GTK application I use (mostly Firefox and several > games, Eclipse, Gimp) has segfaulted AFAICR, at least not the way > Emacs has been doing, right on startup, since I first installed wxGTK. > (There are at least two other issues I've had with GTK-Emacs that I've > not had with any other GTK application, but they have to do > specifically with KDE and not with wxGTK or fonts, so I assume they > are not related to this problem, except (and that in itself is perhaps > significant) for being restricted to Emacs.) > > Steve Berman > ___ > Here's the backtrace from last night's segfault: > > [EMAIL PROTECTED]:/users/steve/cvsroot/emacs/src> gdb emacs > GNU gdb 6.4 > Copyright 2005 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There
Re: Cursor placement with mouse in long lines with wrapped tab
> "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 (sparc-sun-solaris2.8, Motif Version 2.1.0) >> of 2006-11-28 on sfsws4 Chris> Chris> I can't reproduce that behaviour in "GNU Emacs 22.0.91.24 Chris> (i686-pc-linux-gnu, GTK+ Version 2.8.20)\n of 2006-12-06 on chrislap" Chris> - could you try rebuilding from newer sources and see if it still Chris> happens? I have the patch installed that Chong suggested and with this patch it works fine. But when I remove Chong's patch, the bug is reproducible again. Klaus -- -- | Klaus Zeitler Alcatel-Lucent | | Email: [EMAIL PROTECTED] | -- --- Injustice anywhere is a threat to justice everywhere.-- Martin Luther King, Jr. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: emacsclient and emacsclientw don't work in Windows Vista x64 RTM
> Date: Mon, 11 Dec 2006 19:25:59 +0100 > From: Lennart Borgman <[EMAIL PROTECTED]> > CC: [EMAIL PROTECTED], [EMAIL PROTECTED], > emacs-pretest-bug@gnu.org > > I changed my routines just a little bit so I now upload also a zip file > with nothing but precompiled Windows binaries of Emacs. However this is > straight from the CVS, not the pretest tar balls. I see no big problem > with that however. I do see a problem: we want people to try the pretest, not the CVS. For example, the recently reported problem with cus-load.el is not visible in the CVS version. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Customize: New Options
> 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 a bootstrap does. > > That's strange. Maybe there was a glitch when I rolled the last > pretest tarball; make-dist seems to copy in cus-load OK. 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. The previous pretest did include cus-load.el, btw. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: warnings compiling Emacs 22 on amd64
> 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 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. > Such a comparison is useless, because the compiler knows that the > constant long is always bigger than the int, due to its size. I tried > to avoid the comparison by changing the FIXNUM_OVERFLOW_P macro like > this: > > #define FIXNUM_OVERFLOW_P(i) \ > (sizeof(i) >= sizeof(EMACS_INT) \ >&& ((EMACS_INT)(i) > MOST_POSITIVE_FIXNUM \ >|| (EMACS_INT)(i) < MOST_NEGATIVE_FIXNUM)) > > that is, by adding a test on sizeof at the beginning. However, this has > no effect and the following warnings are always there: If FIXNUM_OVERFLOW_P should always return zero on 64-bit machines, then how about changing FIXNUM_OVERFLOW_P so that it's a constant on 64-bit machines? For example: #ifdef _LP64 # define FIXNUM_OVERFLOW_P(i) 0 #else # define FIXNUM_OVERFLOW_P(i) \ ((EMACS_INT)(i) > MOST_POSITIVE_FIXNUM \ || (EMACS_INT) (i) < MOST_NEGATIVE_FIXNUM) #endif Does this fix the problem? (But I still would like to understand why the comparison is always true.) > Doing like this: > > #define FIXNUM_OVERFLOW_P(i) \ > ((sizeof(i) < sizeof(EMACS_INT)) ? 0 \ >: ((EMACS_INT)(i) > MOST_POSITIVE_FIXNUM \ >|| (EMACS_INT)(i) < MOST_NEGATIVE_FIXNUM)) > > still changes nothing. Apparently the compiler runs the second test > even if the first one fails, and so issues a warning. I don't think the code is ``run'', but it is definitely analyzed by the parser, and that is when you get the warning. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Customize: New Options
> 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. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: emacsclient and emacsclientw don't work in Windows Vista x64 RTM
Eli Zaretskii wrote: Date: Thu, 7 Dec 2006 23:55:58 -0800 From: "Deutsch, Will" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, I was specifically asked to provide the / vs \ output of Dir. Sorry, I missed that. Lennart, can you tell why you asked for that, and what does it have to do with the original problem? (Did I explain why before? I think I missed it.) In a cmd.exe console window you can actually do things like C:\> dir "c:/path/to/my/files/dir/" It works as long as the last component is not a file instead of a directory. Then it fails. I did not notice that last case when I tested so I believed it worked in all cases on w2k, that is why I asked Will to test. So, yes, it was a useless test unfortunately ;-) Now I am just waiting for Will's report with using my patched version of emacsclient.exe where I have changed path to Emacs bin dir to use only \ before calling CreateProcess. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: GTK build crashes under X
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 may be a bad font (I don't know what cu12.pcf is, > Courier 12?). According to the output of strings it is: -MUTT-ClearlyU-Medium-R-Normal--17-120-100-100-P-123-ISO10646-1. According to http://www.xfree86.org/current/fonts3.html, /usr/X11R6/lib/X11/fonts/misc/cu12.pcf.gz is the "main ClearlyU font" and this "family of fonts provides a set of 12 pt, 100 dpi proportional fonts with many of the glyphs needed for Unicode text". According to that source, the full font name has 101 instead of 123 in the width slot; I wonder if that is relevant to my problem? I grepped the Emacs sources for ClearlyU (ignoring case) and got no hits. > An idea why Emacs crashes and no other may be that Emacs uses only > non-AA fonts, whereas Firefox and other uses AA fonts mostly. But > it is hard to tell. The next time I get a segfault, I'll try to see if removing that font helps (though I wonder if it will have bad consequences for other applications ...). > If removing that file doesn't help, you could try to switch to a > more basic theme. It hadn't occurred to me to try switching themes. I use the gtk-qt-engine, which allows Gtk applications to use the selected KDE theme. I don't know if this is related, but this theme used to cause a problem for Emacs (and only Emacs among Gtk applications), namely, the color of the non-text part of the Emacs frame could not be changed by setting the background-color face in Emacs (that is, the background color only showed behind textual character; the rest of the window a different color). Other Gtk themes did not have this problem. Then I found on the web a report that compiling the gtk-qt-engine from source solves similar issues and I tried that and it indeed solved the Emacs problem. > But all this is just shots in the dark, I'm afraid. Thanks for your suggestions. Steve Berman ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: warnings compiling Emacs 22 on amd64
> 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 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). > If FIXNUM_OVERFLOW_P should always return zero on 64-bit machines, It shouldn't. There are a few sites where it does, tho. > then how about changing FIXNUM_OVERFLOW_P so that it's a constant on > 64-bit machines? For example: > #ifdef _LP64 > # define FIXNUM_OVERFLOW_P(i) 0 > #else > # define FIXNUM_OVERFLOW_P(i) \ > ((EMACS_INT)(i) > MOST_POSITIVE_FIXNUM \ > || (EMACS_INT) (i) < MOST_NEGATIVE_FIXNUM) > #endif > Does this fix the problem? What problem? There is no problem other than unhelpful warnings. The warnings basically say "hey guys, I found an optimization opportunity" and we're very happy that gcc does the optimization: it saves us from trying to write ugly and brittle code such as the one above. Too bad gcc is a bit noisy in this case. We can probably remove those warnings with the right -Wno-foo invocation. > (But I still would like to understand why the comparison is always > true.) It's only "always true" in some specific contexts. Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
M-x grep in buffer *grep* puts you at the end of the grep output
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 annoying.
In GNU Emacs 22.0.91.1 (i386-mingw-nt5.1.2600)
of 2006-12-11 on LENNART-69DE564
X server distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4) --cflags -Id:/g/include'
Important settings:
value of $LC_ALL: nil
value of $LC_COLLATE: nil
value of $LC_CTYPE: nil
value of $LC_MESSAGES: nil
value of $LC_MONETARY: nil
value of $LC_NUMERIC: nil
value of $LC_TIME: nil
value of $LANG: ENU
locale-coding-system: cp1252
default-enable-multibyte-characters: t
Major mode: Grep
Minor modes in effect:
encoded-kbd-mode: t
tooltip-mode: t
tool-bar-mode: t
mouse-wheel-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
unify-8859-on-encoding-mode: t
utf-translate-cjk-mode: t
auto-compression-mode: t
line-number-mode: t
Recent input:
y C-g C-g C-g C-x b C-x C-f s e t u
p C-g C-g C-x b C-s c y g C-s C-s C-s C-a
C-x C-e
M-x g r e p c o m m e n t s SPC * . e l
C-x b M-x g r e p
M-p C-x 0 M-x g r e p M-p
Recent messages:
drews-lisp-dir
("C:\\drews-lisp-20" "c:/Emacs-22-2006-12-11-Lennart/site-lisp"
"C:/Emacs-22-2006-12-11-Lennart/../site-lisp"
"C:/Emacs-22-2006-12-11-Lennart/lisp"
"c:/Emacs-22-2006-12-11-Lennart/lisp/calc"
"c:/Emacs-22-2006-12-11-Lennart/lisp/calendar"
"c:/Emacs-22-2006-12-11-Lennart/lisp/emacs-lisp"
"c:/Emacs-22-2006-12-11-Lennart/lisp/emulation"
"c:/Emacs-22-2006-12-11-Lennart/lisp/erc"
"c:/Emacs-22-2006-12-11-Lennart/lisp/eshell"
"c:/Emacs-22-2006-12-11-Lennart/lisp/gnus"
"c:/Emacs-22-2006-12-11-Lennart/lisp/international" ...)
Mark set
("C:\\drews-lisp-20/CONTRIB" "C:\\drews-lisp-20/CONTRIB/tty-color"
"C:\\drews-lisp-20/CONTRIB/ps-print" "C:\\drews-lisp-20/CONTRIB/ebnf2ps"
"C:\\drews-lisp-20/CONTRIB/gnuserv" "C:\\drews-lisp-20/CONTRIB/cc-mode-5.27"
"C:\\drews-lisp-20/CONTRIB/nxml-mode-20041004"
"C:\\drews-lisp-20/CONTRIB/mmm-mode-0.4.8"
"C:\\drews-lisp-20/CONTRIB/html-helper-mode"
"C:\\drews-lisp-20/CONTRIB/psgml-1.2.5" "C:\\drews-lisp-20/CONTRIB/tdtd"
"C:\\drews-lisp-20/CONTRIB/xslide-0.2.2" ...)
Quit [5 times]
Mark saved where search started
Loading sort...done
setup-cygwin
Loading grep...done
Loading emacsbug...done
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Can't display Japanese text in menu bar
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 "\e$B%F%9%H\e(B" 'iso-2022-jp)))
(easy-menu-define testing-menu global-map "Testing."
`("Testing"
[,japanese (lambda nil (interactive) (message ,japanese)) t]))
(easy-menu-add testing-menu global-map))
I found the way to make it work. That is to re-set the font for
the `menu' face as follows:
(set-face-font 'menu (face-font 'menu))
But I don't think this is the right way. WDYT?
Regards,
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Customize: New Options
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? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Directory name completion blocks when it shouldn't
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 a predicate argument as well; it could default to one that ignored certain extensions (as the function does now). I would like someone to look at implementing this. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: emacsclient and emacsclientw don't work in Windows Vista x64 RTM
> 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 before? I think I missed it.) No, you didn't explain this before. > In a cmd.exe console window you can actually do things like > >C:\> dir "c:/path/to/my/files/dir/" > > It works as long as the last component is not a file instead of a > directory. Then it fails. I did not notice that last case when I tested > so I believed it worked in all cases on w2k, that is why I asked Will to > test. So, yes, it was a useless test unfortunately ;-) > > Now I am just waiting for Will's report with using my patched version of > emacsclient.exe where I have changed path to Emacs bin dir to use only \ > before calling CreateProcess. I don't see why this should matter, since the Windows API groks both forward and backslashes, AFAIK. But if you think this could be the problem, how about writing a short program that uses CreateProcess, similarly to emacsclient, to start a program whose name it gets via the command line? Then Will and others could try that program with various variants of file names using different mixes of forward and back-slashes, and see if that matters at all. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: warnings compiling Emacs 22 on amd64
> 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 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, like `(EMACS_INT)i + 0L' or `(EMACS_INT)i*1L'? > > If FIXNUM_OVERFLOW_P should always return zero on 64-bit machines, > > It shouldn't. There are a few sites where it does, tho. Are these few cases those for which the argument of FIXNUM_OVERFLOW_P is an int (rather than a long)? > > Does this fix the problem? > > What problem? The warning messages. > There is no problem other than unhelpful warnings. > The warnings basically say "hey guys, I found an optimization opportunity" > and we're very happy that gcc does the optimization: it saves us from trying > to write ugly and brittle code such as the one above. Too bad gcc is a bit > noisy in this case. We can probably remove those warnings with the > right -Wno-foo invocation. I don't think we want to remove this warning in general with -W-no-* because it could point out bugs, and I don't think we like to see warnings where the code is correct. You are free to think otherwise, of course, but please let us try to resolve that anyway. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: emacsclient and emacsclientw don't work in Windows Vista x64 RTM
> 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 could I > try to report this (potential) bug? According to this: http://msdn2.microsoft.com/en-us/library/1w06ktdy(VS.80).aspx the Windows version of `access' doesn't support X_OK at all, only F_OK, R_OK, and W_OK. I don't really understand why did you need that test. The CVS version of emacsclient.c doesn't have such a test, AFAICS. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: warnings compiling Emacs 22 on amd64
>> 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, like `(EMACS_INT)i + 0L' or `(EMACS_INT)i*1L'? Could be, or maybe not. My guess is that the optimization scheme uses an abstract domain where integer values are approximated by bounds (so a char is approximated by [-128..127]), so "+1" should be handled just fine (after conversion to EMACS_INT this same char is still [-128..127] and since "1" is most likely approximated by [1..1], then the sum of the two will be approximated by [-127..128]). But why should it matter whether it does or not? >> > If FIXNUM_OVERFLOW_P should always return zero on 64-bit machines, >> It shouldn't. There are a few sites where it does, tho. > Are these few cases those for which the argument of FIXNUM_OVERFLOW_P > is an int (rather than a long)? At least these, maybe others as well. >> > Does this fix the problem? >> What problem? > The warning messages. >> There is no problem other than unhelpful warnings. >> The warnings basically say "hey guys, I found an optimization opportunity" >> and we're very happy that gcc does the optimization: it saves us from trying >> to write ugly and brittle code such as the one above. Too bad gcc is a bit >> noisy in this case. We can probably remove those warnings with the >> right -Wno-foo invocation. > I don't think we want to remove this warning in general with -W-no-* > because it could point out bugs, and I don't think we like to see > warnings where the code is correct. You are free to think otherwise, > of course, but please let us try to resolve that anyway. I agree with the intention but I wouldn't want to "fix" the warnings by applying the optimization by hand, unless the code after optimization is just as clean and maintainable. Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
