TAB in rcirc barfs.
Please write in English if possible, because the Emacs maintainers usually do not have translators to read other languages for them. Your bug report will be posted to the emacs-pretest-bug@gnu.org mailing list. Please describe exactly what actions triggered the bug and the precise symptoms of the bug: M-x irc RET TAB gives Debugger entered--Lisp error: (wrong-type-argument stringp nil) assoc-string(nil ((#emacs 17447 25645 77605)) t) #[(k v) Å Æ#... \nAB\fB.). [channel v record k nicks assoc-string t] 5](dak` ((#emacs 17447 25645 77605))) maphash(#[(k v) Å Æ#... \nAB\fB.). [channel v record k nicks assoc-string t] 5] #hash-table 'equal nil 185/217 0x99c7598) rcirc-channel-nicks(#process irc.freenode.net nil) rcirc-complete-nick() call-interactively(rcirc-complete-nick) In GNU Emacs 22.0.50.32 (i686-pc-linux-gnu, GTK+ Version 2.8.6) of 2006-03-25 on lola X server distributor `The X.Org Foundation', version 11.0.60802000 configured using `configure '--prefix=/usr/local/emacs-21' '--with-gtk' '--without-toolkit-scroll-bars'' 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: en_US.UTF-8 locale-coding-system: utf-8 default-enable-multibyte-characters: t Major mode: Debugger Minor modes in effect: TeX-PDF-mode: t desktop-save-mode: t iswitchb-mode: t minibuffer-electric-default-mode: t tooltip-mode: t auto-compression-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-decoding-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t line-number-mode: t -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
file-cache doc should state that the cache is non-persistent
Looking at both the File Name Cache node in the Emacs manual and the Lisp source code, I see nothing that indicates whether or not the cache is persistent. This is an important piece of information. The doc should make it clear that the cache is not persistent and that it launches `find' each time you use it to find a file. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Menu bar is skrewed up when using filesets
On Mon, 20 Mar 2006 14:44:52 +0100, Martin Buchmann [EMAIL PROTECTED] said: After I erased all of the customization for the filesets section and the ~/.filesets-cache.el file, filesets are working fine again. Nevertheless, I don't understand how a corrupted cache file or a wrong customization could lead to this behaviour. Then it seems to be difficult for us to know what was wrong without your customization and the cache file. If you feel uncomfortable to make them public by sending them to the list, can you send them to me directly? YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: mouse cursor bug?
Leon [EMAIL PROTECTED] writes: Hi all, I finally figure out how to reproduce this bug though I have known it for a while. 1. Fire up gnus 2. middle click a group with a small number of unread articles so that you won't be interrupted to enter the number of articles. Make sure you mouse cursor won't be on any clickable text when enter the group. *NB*: You may need to hold down the middle button slightly longer than usual when middle click the group. Your mouse cursor will still has a 'hand shape' after entering the group. I have recorded this process in a gif file located here: http://people.pwf.cam.ac.uk/sl392/emacs/emacs_cursor.gif Hope you can reproduce this and fix it. This bug has *NOT* been fixed in CVS 20060325. The above is just an example to reproduce it. It happens even with Mouse-1 click. I have found it annoying since it gives a wrong visual hint. Could anybody has similar experience confirm? -- Leon GNU Emacs 23.0.0.1 (i686-pc-linux-gnu, GTK+ Version 2.8.15) of 2006-03-25 on sl392 ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: old bootstrap error emerges again
Eli Zaretskii [EMAIL PROTECTED] writes: Cc: Eli Zaretskii [EMAIL PROTECTED], emacs-pretest-bug@gnu.org, emacs-devel@gnu.org From: Jason Rumney [EMAIL PROTECTED] Date: Sat, 25 Mar 2006 19:58:14 + Dieter Deyke [EMAIL PROTECTED] writes: 390 if (SUBRP (fun)) (gdb) 392 if (XSUBR (fun)-doc == 0) (gdb) 394 else if ((EMACS_INT) XSUBR (fun)-doc = 0) Could it be that we are not explicitly setting doc to 0, and Dieter's compiler is initializing its memory with something other than 0 to detect this type of bug? Well, I think we both are using the same compiler, modulo the version. Dieter, what does your compiler say when invoked with --version, and what version of the MinGW runtime do you have installed? Also, did any of these change lately on the machine where the problem disappeared? [EMAIL PROTECTED] bin]$ ./gcc --version gcc.exe (GCC) 3.2.3 (mingw special 20030504-1) Copyright (C) 2002 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. MinGW version 3.1.0 contains the following list of packages: GCC-3.2.3-20030504-1.tar.gz binutils-2.13.90-20030111-1 mingw-runtime-3.1 w32api-2.4 gdb-5.2.1-1 mingw32-make-3.80.0-3 mingw-utils-0.2.tar.gz There is no difference between the 2 PCs (working and non-working) that I am aware of, and the tools did not change for a few weeks. But when I said I only have MinGW and cygwin, I oversimplified. The reality is that I have the following stuff in the path (in that order): MinGW is first the combined bin directory resulting from installing the following packages from the gnuwin32 site is second: GnuWin32 Packages.URL giflib-4.1.4-bin.zip libpng-1.2.8-dep.zip tiff-3.8.2-doc.zip MinGW - Download.URLgiflib-4.1.4-dep.zip libpng-1.2.8-doc.zip tiff-3.8.2-lib.zip MinGW-3.1.0-1.exe giflib-4.1.4-doc.zip libpng-1.2.8-lib.zip tiff-3.8.2-src.zip coreutils-5.3.0-bin.zip giflib-4.1.4-lib.zip libpng-1.2.8-src.zip xpm-3.5.1-1-bin.zip coreutils-5.3.0-dep.zip giflib-4.1.4-src.zip mingw32-make-3.80.0-3.tar.gz xpm-3.5.1-1-doc.zip coreutils-5.3.0-doc.zip jpeg-6b-4-bin.zip texinfo-4.8-bin.zip xpm-3.5.1-1-lib.zip coreutils-5.3.0-src.zip jpeg-6b-4-dep.zip texinfo-4.8-dep.zip xpm-3.5.1-1-src.zip findutils-4.2.20-2-bin.zip jpeg-6b-4-doc.zip texinfo-4.8-doc.zip zlib-1.2.3-bin.zip findutils-4.2.20-2-dep.zip jpeg-6b-4-lib.zip texinfo-4.8-src.zip zlib-1.2.3-doc.zip findutils-4.2.20-2-doc.zip jpeg-6b-4-src.zip tiff-3.8.2-bin.zip zlib-1.2.3-lib.zip findutils-4.2.20-2-src.zip libpng-1.2.8-bin.zip tiff-3.8.2-dep.zip zlib-1.2.3-src.zip Next in path is cygwin and the usual Windows stuff. Given this setup here are some version strings: C:\Users\deyke\emacs-buildset PATH=C:\MinGW\bin;C:\Users\deyke\emacs-build\\bin ;C:\Program Files\Wonderful;.;tools;c:\Users\deyke\.bin;C:\cygwin\bin;C:\cygwin\ usr\X11R6\bin;C:\Python24;C:\Python24\Scripts;C:\emacs\bin;C:\Program Files\Micr osoft IntelliType Pro;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C: \Program Files\OpenVPN\bin;C:\Program Files\mplayer;C:\Program Files\Executive S oftware\Diskeeper;C:\Software\Unison;C:\Program Files\Subversion\bin;C:\Program Files\Aspell\bin;C:\Program Files\QuickTime\QTSystem C:\Users\deyke\emacs-buildgcc --version gcc (GCC) 3.2.3 (mingw special 20030504-1) Copyright (C) 2002 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. C:\Users\deyke\emacs-buildmake --version GNU Make 3.80 Copyright (C) 2002 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. C:\Users\deyke\emacs-buildsh --version GNU bash, version 3.00.16(14)-release (i686-pc-cygwin) Copyright (C) 2004 Free Software Foundation, Inc. -- Dieter Deyke mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Vs lbh pna ernq guvf, lbh unir jnl gbb zhpu gvzr. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
tar-mode in GNU Emacs 23.0.0 cannot count, select ...
Hello! When viewing a gzip'ed tar file a message like 'tar-view: Args out of range: 10060955, 10072067' can be displayed. Viewing the same file in the same archive with GNU Emacs 22.0.50 no such message comes up. Viewing a file README in that same archive shows in GNU Emacs 22.0.50 a readable text, in GNU Emacs 23.0.0 it seems to be binary. Looking into the preceding PNG file I can see at its end the second and the third line of the README file, eight ASCII NUL (^@) follow, no newline. Doing a CVS update 16:50 MESZ (UTC+2) brings no new Lisp or C code, so a simple make is started. Gcc used is 'gcc version 4.0.0 20041026 (Apple Computer, Inc. build 4061), Thread model: posix.' The new version exhibits the same behaviour, launching it with -Q does not change it. It seems as if the archive needs to have a size of some MB. ZIP files seem to work, although I once received 'archive_get_descr: Entry is not a regular member of the archive' -- the archive came from Mac OS X ... In GNU Emacs 23.0.0.1 (powerpc-apple-darwin8.5.0, X toolkit, Xaw3d scroll bars) of 2006-03-26 on localhost X server distributor `The XFree86 Project, Inc', version 11.0.4040 configured using `configure '--without-sound' '--without-pop' '--with- xpm' '--with-jpeg' '--with-tiff' '--with-gif' '--with-png' '--enable- locallisppath=/Library/Application Support/Emacs/calendar22:/Library/ Application Support/Emacs/preview:/Library/Application Support/Emacs/ auctex/images:/Library/Application Support/Emacs/auctex:/Library/ Application Support/Emacs' 'CFLAGS=-ggdb -O2 -pipe -faltivec - maltivec -mabi=altivec -mcpu=7450 -no-cpp-precomp -fomit-frame- pointer -foptimize-register-move -fcprop-registers -frename-registers -freorder-blocks -fpeephole -mpowerpc-gfxopt -mpowerpc-gpopt' 'CPPFLAGS=-I/usr/local/include -I/sw/include/libpng12 -I/sw/lib/pango- ft219/include -I/sw/include/pango-1.0 -I/sw/lib/freetype219/include - I/sw/include' 'LDFLAGS=-dead_strip -L/usr/X11R6/lib -L/usr/local/lib - L/sw/lib/ncurses -L/sw/lib/freetype219/lib -L/sw/lib/pango-ft219/lib - L/sw/lib'' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: de_DE.UTF-8 value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: de_DE.UTF-8 locale-coding-system: utf-8 default-enable-multibyte-characters: t Major mode: Fundamental Minor modes in effect: TeX-PDF-mode: t desktop-save-mode: t display-time-mode: t show-paren-mode: t tooltip-mode: t auto-compression-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 global-auto-composition-mode: t auto-composition-mode: t column-number-mode: t line-number-mode: t transient-mark-mode: t view-mode: t -- Mit friedvollen Grüßen Pete It's not the valleys in life I dread so much as the dips. -- Garfield ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
balance-windows causes core dump
On my GNU/Linux system here, I can crash Emacs as follows: emacs -Q C-x 2 M-x balance-windows RET Emacs fatal error: window.c:4292: assertion failed: GC_WINDOWP(parent) Fatal error (6)zsh: abort (core dumped) ../../trunk/src/emacs -Q I don't have time to look into it right now, but the problem is in adjust-window-trailing-edge. And it's only correctly caught if you compile with ENABLE_CHECKING. Stefan #0 0xb7c1dbf1 in kill () from /lib/tls/libc.so.6 #1 0x081306bc in abort () at emacs.c:464 #2 0x0819ce06 in die (msg=0x0, file=0x0, line=0) at alloc.c:6199 #3 0x080beed3 in Fadjust_window_trailing_edge (window=138362889, delta=-8, horizontal=138362889) at window.c:4290 #4 0x081bd903 in Feval (form=137729213) at eval.c:2247 #5 0x081c0aab in internal_lisp_condition_case (var=138707377, bodyform=137729213, handlers=137729245) at eval.c:1418 #6 0x081f6440 in Fbyte_code (bytestr=137729139, vector=137729188, maxdepth=3) at bytecode.c:884 #7 0x081be16f in funcall_lambda (fun=value optimized out, nargs=3, arg_vector=0xbf8d77c4) at eval.c:3088 #8 0x081be739 in Ffuncall (nargs=4, args=0xbf8d77c0) at eval.c:2956 #9 0x081f7259 in Fbyte_code (bytestr=137729451, vector=137729772, maxdepth=6) at bytecode.c:694 #10 0x081be16f in funcall_lambda (fun=value optimized out, nargs=3, arg_vector=0xbf8d78f4) at eval.c:3088 #11 0x081be739 in Ffuncall (nargs=4, args=0xbf8d78f0) at eval.c:2956 #12 0x081f7259 in Fbyte_code (bytestr=137729451, vector=137729772, maxdepth=6) at bytecode.c:694 #13 0x081be16f in funcall_lambda (fun=value optimized out, nargs=3, arg_vector=0xbf8d7a24) at eval.c:3088 #14 0x081be739 in Ffuncall (nargs=4, args=0xbf8d7a20) at eval.c:2956 #15 0x081f7259 in Fbyte_code (bytestr=137728699, vector=137728916, maxdepth=9) at bytecode.c:694 #16 0x081be16f in funcall_lambda (fun=value optimized out, nargs=0, arg_vector=0xbf8d7b64) at eval.c:3088 #17 0x081be739 in Ffuncall (nargs=1, args=0xbf8d7b60) at eval.c:2956 #18 0x081c0758 in apply1 (fn=140510433, arg=138362889) at eval.c:2646 #19 0x081ba1c0 in Fcall_interactively (function=140510433, record_flag=138362937, keys=138419788) at callint.c:412 #20 0x0813ce3d in Fcommand_execute (cmd=140510433, record_flag=138362937, keys=0, special=138362889) at keyboard.c:9768 #21 0x0813d241 in Fexecute_extended_command (prefixarg=138362889) at keyboard.c:9878 #22 0x081be9c5 in Ffuncall (nargs=2, args=0xbf8d7e90) at eval.c:2901 #23 0x081b9fe2 in Fcall_interactively (function=138420281, record_flag=138362889, keys=138419788) at callint.c:884 #24 0x0813ce3d in Fcommand_execute (cmd=138420281, record_flag=138362889, keys=0, special=138362889) at keyboard.c:9768 #25 0x08149248 in command_loop_1 () at keyboard.c:1791 #26 0x081bc0b2 in internal_condition_case (bfun=0x8148c70 command_loop_1, handlers=138423929, hfun=0x813e010 cmd_error) at eval.c:1473 #27 0x081337be in command_loop_2 () at keyboard.c:1328 #28 0x081bbcfc in internal_catch (tag=0, func=0x8133790 command_loop_2, arg=138362889) at eval.c:1211 #29 0x0813336e in command_loop () at keyboard.c:1307 #30 0x08133414 in recursive_edit_1 () at keyboard.c:1000 #31 0x08133596 in Frecursive_edit () at keyboard.c:1061 #32 0x0813218f in main (argc=2, argv=0xbf8d8754) at emacs.c:1789 ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
image file with Chinese file names
[ this was originally posted to [EMAIL PROTECTED] ] I'm seeing something that I'm not sure is necessary. When I use create-image with file with chinese name like this, image-size always return (30 . 30) as its size: (30 is the default size when image cannot be loaded according to emacs C source code). (image-size (create-image image-file-name) t) if I do this: (image-size (create-image (encode-coding-string image-file-name 'big5)) t) It returns correct size. I'm wondering if encode-coding-string is necessary here. My file-name-coding-system is already set to big5. Please note that in both cases, the image file itself can be displayed properly. It's just the image-size seems to have problem. I'm running CVS emacs on Windows XP. MJ --- In GNU Emacs 22.0.50.1 (i386-mingw-nt5.1.2600) of 2006-01-22 on BASE X server distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.2) --cflags -I../../GnuWin32/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: chinese-big5 default-enable-multibyte-characters: t Major mode: Fundamental Minor modes in effect: auto-image-file-mode: t encoded-kbd-mode: t tooltip-mode: t auto-compression-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t line-number-mode: t Recent input: l o c tab a tab m i tab / o u tab return C-n C-n C-p C-p C-x C-k C-x n C-x n C-n C-n C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-x C-k x help-echo M-x m s p tab return g C-n q help-echo help-echo M-x e backspace r e p o tab backspace backspace backspace backspace e m a c tab r e tab backspace backspace backspace backspace backspace backspace backspace backspace r e p o tab r backspace o tab backspace backspace o r t - e m tab return Recent messages: 1 of 1 deletions 1 deletion done line-move-1: Beginning of buffer [3 times] No changes need to be saved Loading mspools-extra...done Loading vm-pop...done Making completion list... [2 times] Loading emacsbug...done ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
flyspell-buffer does not detect mistyped words with umlauts on Win32 + workaround
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 report will be posted to the emacs-pretest-bug@gnu.org mailing list. Please describe exactly what actions triggered the bug and the precise symptoms of the bug: When running flyspell-buffer on a LaTeX buffer that has German umlauts in it (using dictionary german8), it ignores any words with umlauts, i. e. it won't complain for wrong words and not for correct words either. Instead, the *Messages* contains word not found messages for parts of these words. When setting `flyspell-large-region' to nil, it works perfectly (but much slower). So the problem has to be in the flyspell-large-region function. Indeed, this function calls `call-process-region' to feed the buffer to ispell. When replacing ispell by a small program that dumps stdin to a file, German umlauts look funny in there, e. g. a ü is encoded as two bytes 0x81 0xFC. So I think it is a coding system problem After some more experiments I found a solution. This simple patch (which is of course not a proper fix since latin-1 is not appropriate for the whole world) makes it work as I think it should. =cut here= --- flyspell.el.orig2006-03-24 14:28:36.0 +0100 +++ flyspell.el 2006-03-24 14:29:40.0 +0100 @@ -1431,6 +1431,7 @@ (if flyspell-issue-message-flag (message Checking region...)) (set-buffer curbuf) (ispell-check-version) +(let ((coding-system-for-write 'iso-8859-1)) (let ((c (apply 'call-process-region beg end ispell-program-name @@ -1460,7 +1461,7 @@ (with-current-buffer curbuf (flyspell-delete-region-overlays beg end)) (flyspell-external-point-words)) - (error Can't check region...) + (error Can't check region...)) ;;*-*/ ;;*flyspell-region ... */ =cut here= In GNU Emacs 22.0.50.1 (i386-mingw-nt5.1.2600) of 2005-12-18 on NEUTRINO X server distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4) --cflags -Ic:/Programme/GnuWin32/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: DEU locale-coding-system: cp1252 default-enable-multibyte-characters: t Major mode: LaTeX Minor modes in effect: iswitchb-mode: t partial-completion-mode: t delete-selection-mode: t pc-selection-mode: t recentf-mode: t show-paren-mode: t encoded-kbd-mode: t tooltip-mode: t auto-compression-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 line-number-mode: t transient-mark-mode: t ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: old bootstrap error emerges again
Eli Zaretskii [EMAIL PROTECTED] writes:
From: Dieter Deyke [EMAIL PROTECTED]
Cc: emacs-pretest-bug@gnu.org, emacs-devel@gnu.org
Date: Sat, 25 Mar 2006 08:54:45 -0700
The strange thing is that the error vanished yesterday on my work PC,
but using the same tools I still get it on my home PC:
Do you have the same sources (i.e. the same CVS check-out) on both of
these machines?
I'm not sure, but I guess so. The error vanished on my work PC with
CVS sources from yesterday afternoon, and it is still here on my home
PC with CVS sources from this morning.
Starting program: C:\Users\deyke\emacs-build\work\lisp/../bin/my-emacs.exe
-batc
h --no-init-file --no-site-file --multibyte -f batch-byte-compile
url/vc-dav.el
Breakpoint 3, get_doc_string (filepos=-2581128, unibyte=0, definition=0)
at doc.c:196
196 error (Cannot open doc string file \%s\, name);
(gdb) up 1
#1 0x0110da05 in Fdocumentation (function=27819993, raw=27674673) at
doc.c:456
456 tem = get_doc_string (doc, 0, 0);
(gdb) print function
$1 = 27819993
(gdb) xtype
Lisp_Symbol
(gdb) xsymbol
$2 = (struct Lisp_Symbol *) 0x1a87fd8
file-exists-p
(gdb)
Thanks. Now please repeat this again, and this time put a breakpoint
in Fdocumentation; when it breaks, verify that the first argument is
indeed file-exists-p, and then step through the code until it calls
get_doc_string and tell me what you saw. When I do that on my system,
what I see is below. As you see, Fdocumentation returns nil without
ever calling get_doc_string. Can you find out what is different on
your machine, and why?
As for your last question, I'm not using MSYS. My setup includes:
english XP Pro SP2
current cygwin
MinGW-3.1.0-1 in PATH before cygwin
Okay, so perhaps Cygwin has something to do with this. Hopefully, we
will understand that when we find the reason for the different
behavior.
Here's a transcript of the GDB session on my machine:
D:\gnu\test\emacs\lispgdb ../bin/bootstrap-emacs.exe
GNU gdb 6.3
Copyright 2004 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 i686-pc-mingw32...
(gdb) br Fdocumentation
Breakpoint 1 at 0x10fc4e0: file doc.c, line 378.
(gdb) source ../src/.gdbinit
Environment variable DISPLAY not defined.
Environment variable TERM not defined.
Breakpoint 2 at 0x1133856: file w32fns.c, line 8965.
Breakpoint 3 at 0x109513b: file sysdep.c, line 1395.
(gdb) del 2 3
(gdb) r -batch --no-init-file --no-site-file --multibyte -l loaddefs.el -f
batc
h-byte-compile url/vc-dav.el
Starting program: D:\gnu\test\emacs\lisp/../bin/bootstrap-emacs.exe -batch
--no
-init-file --no-site-file --multibyte -l loaddefs.el -f batch-byte-compile
url/v
c-dav.el
Loading subst-ksc...
Loading subst-gb2312...
Loading subst-big5...
Loading subst-jis...
Breakpoint 1, Fdocumentation (function=44196825, raw=44054577) at doc.c:378
378 int try_reload = 1;
(gdb) p function
$1 = 44196825
(gdb) xtype
Lisp_Symbol
(gdb) xsymbol
$2 = (struct Lisp_Symbol *) 0x2a263d8
file-exists-p
(gdb) n
374 {
(gdb) n
384 if (SYMBOLP (function)
(gdb)
382 doc = Qnil;
(gdb)
384 if (SYMBOLP (function)
(gdb)
382 doc = Qnil;
(gdb)
384 if (SYMBOLP (function)
(gdb)
389 fun = Findirect_function (function, Qnil);
(gdb)
390 if (SUBRP (fun))
(gdb)
392 if (XSUBR (fun)-doc == 0)
(gdb)
409 return Qnil;
(gdb)
477 }
(gdb)
Breakpoint 4, Fdocumentation (function=27819993, raw=27674673) at doc.c:378
378 int try_reload = 1;
(gdb) p function
$3 = 27819993
(gdb) xtype
Lisp_Symbol
(gdb) xsymbol
$4 = (struct Lisp_Symbol *) 0x1a87fd8
file-exists-p
(gdb) n
374 {
(gdb) n
384 if (SYMBOLP (function)
(gdb)
382 doc = Qnil;
(gdb)
384 if (SYMBOLP (function)
(gdb)
382 doc = Qnil;
(gdb)
384 if (SYMBOLP (function)
(gdb)
389 fun = Findirect_function (function, Qnil);
(gdb)
390 if (SUBRP (fun))
(gdb)
392 if (XSUBR (fun)-doc == 0)
(gdb)
394 else if ((EMACS_INT) XSUBR (fun)-doc = 0)
(gdb)
397 doc = make_number ((EMACS_INT) XSUBR (fun)-doc);
(gdb)
451 if (EQ (doc, make_number (0)))
(gdb)
453 if (INTEGERP (doc) || CONSP (doc))
(gdb)
456 tem = get_doc_string (doc, 0, 0);
(gdb)
Breakpoint 3, get_doc_string (filepos=-2581128, unibyte=0, definition=0)
at doc.c:196
196 error (Cannot open doc string file \%s\, name);
(gdb)
--
Dieter Deyke
mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
Vs lbh pna ernq guvf, lbh unir jnl gbb zhpu gvzr.
___
emacs-pretest-bug mailing list
Re: old bootstrap error emerges again
Eli Zaretskii [EMAIL PROTECTED] writes: 390 if (SUBRP (fun)) (gdb) 392 if (XSUBR (fun)-doc == 0) (gdb) 409 return Qnil; (gdb) 477 } (gdb) Dieter Deyke [EMAIL PROTECTED] writes: 390 if (SUBRP (fun)) (gdb) 392 if (XSUBR (fun)-doc == 0) (gdb) 394 else if ((EMACS_INT) XSUBR (fun)-doc = 0) Could it be that we are not explicitly setting doc to 0, and Dieter's compiler is initializing its memory with something other than 0 to detect this type of bug? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: old bootstrap error emerges again
Jason Rumney [EMAIL PROTECTED] writes: Eli Zaretskii [EMAIL PROTECTED] writes: 390 if (SUBRP (fun)) (gdb) 392 if (XSUBR (fun)-doc == 0) (gdb) 409 return Qnil; (gdb) 477 } (gdb) Dieter Deyke [EMAIL PROTECTED] writes: 390 if (SUBRP (fun)) (gdb) 392 if (XSUBR (fun)-doc == 0) (gdb) 394 else if ((EMACS_INT) XSUBR (fun)-doc = 0) Could it be that we are not explicitly setting doc to 0, and Dieter's compiler is initializing its memory with something other than 0 to detect this type of bug? All List_Subr's are statically allocated, it would be a compiler bug if they wouldn't be properly initialized. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
font-lock issue with makefiles
When I open a makefile I get error in the minibuffer with latest cvs.I started emacs with -Q so it's not my .emacs or site-file.Here's what was in the *messages*Fontifying makefile... (regexps) File mode specification error: (error No match 2 in highlight (2 font-lock-variable-name-face))font-lock-fontify-keywords-region: No match 2 in highlight (2 font-lock-variable-name-face)Thanks. If emacs crashed, and you have the emacs process in the gdb debugger,please include the output from the following gdb commands: `bt full' and `xbacktrace'.If you would like to further debug the crash, please read the file /usr/share/emacs/22.0.50/etc/DEBUG for instructions.In GNU Emacs 22.0.50.1 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars)of 2006-03-25 on dev-18.storediq.comX server distributor `The Cygwin/X Project', version 11.0.60802000configured using `configure '--prefix=/usr''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: en_US.UTF-8 locale-coding-system: utf-8 default-enable-multibyte-characters: tMajor mode: Lisp InteractionMinor modes in effect: tooltip-mode: t auto-compression-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 line-number-mode: tRecent input: help-echo help-echo help-echo help-echo menu-bar help-menu report-emacs-bugRecent messages:(emacs -Q)For information about the GNU Project and its goals, type C-h C-p. Loading emacsbug...Loading regexp-opt...doneLoading emacsbug...done ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
