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: Recent 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
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
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
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\lisp>gdb ../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]
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
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 a m i / o u 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 M-x m s p g C-n q M-x e r e p o e m a c r e r e p o r oo r t - e m 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
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=, 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=, 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=, 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=, 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 , handlers=138423929, hfun=0x813e010 ) at eval.c:1473 #27 0x081337be in command_loop_2 () at keyboard.c:1328 #28 0x081bbcfc in internal_catch (tag=0, func=0x8133790 , 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
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
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-build>set 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-build>gcc --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-build>make --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-build>sh --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
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: 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
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
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] #) rcirc-channel-nicks(# 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