Re: loaddefs.el on Windows incomplete
* Eli Zaretskii (2005-12-24) writes: I installed a change that should fix this problem for you. Can you sync with the repository and see if autoloads now work even with MSYS munging of the command line? Thanks for your efforts. I did a fresh checkout into a new directory, ran `configure ...' and while doing `mingw32-make bootstrap' the following error occurred: --8---cut here---start-8--- ./../bin/emacs.exe -batch --no-init-file --no-site-file --multibyte -l autoload \ --eval '(setq find-file-hook nil find-file-suppress-same-file-warnings t)' \ -f w32-batch-update-autoloads D:/software/windows/unix/src/emacs-22.0.50-clean-build/lisp/loaddefs.el . calc calendar emacs-lisp emulation eshell gnus international language mail mh-e net obsolete play progmodes term textmodes url Wrong type argument: symbolp, 0 mingw32-make[1]: *** [autoloads] Error -1 mingw32-make[1]: Leaving directory `D:/software/windows/unix/src/emacs-22.0.50-clean-build/lisp' mingw32-make: *** [bootstrap-gmake] Error 2 --8---cut here---end---8--- In order to get a backtrace I set `debug-on-error' to t via the --eval statement above. That means I edited lisp/makefile.w32-in accordingly and ran `configure' again. Interestingly the error did not occur with this change. I tried this both in the directory where the make call failed with the original makefile.w32-in and in a directory which had not seen a make call before. Same results. Then I tried to run `mingw32-make bootstrap' in a freshly checked out and configured directory including the patch I proposed for lisp/makefile.w32-in and got the same error as above. Let-binding `debug-on-error' to t made the error vanish again. Now I don't really know where to look for the cause of the error. Anyway, in the directories where the build succeeded I did a `diff -u loaddefs.el ldefs-boot.el' which showed no differences between the files. The build I did about a week ago (with the patch I proposed) shows lots of differences between the files. So I am not really sure if loaddefs.el was generated correctly. -- Ralf ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: font-lock-add-keywords in hi-lock.el
Juri Linkov [EMAIL PROTECTED] writes: I just did another update this morning and now the highlighting goes away in Gnus buffers even faster than before (or I just got lucky with what I was doing). I managed to reproduce it twice already this morning. When this happens, I also notice that the highlighting is also broken in *Help* buffers. I think it was last week where I didn't observe this behavior at all. Hard to say if I got lucky, or whether there was a good change a week before that and a bad change this week. But it's what I observed. Sorry, this is so sporadic that I haven't been able to generate a recipe to reproduce it yet. Do you use Hi-Lock (either by putting global-hi-lock-mode in .emacs or by using highlight-regexp or other hi-lock functions)? Not explicitly. Here are my buffers and their modes. I just fired up Gnus with this set and the highlighting was off. Do you know if any of the modes listed below might be triggering the bug? . * *followup to Juri Li: 1305 Message ~/var/news/drafts/drafts/1 %* *Summary gmane.emacs: 1080 Summary %* *Article* 1071 Article %* *Group*614 Group % +inbox1120 MH-Folder ~/var/mail/inbox/ % show-+mhe-index/sequ: 2006 MH-Show ~/var/mail/mhe-index/sequence/unseen/1 % +mhe-index/sequence/u: 99 MH-Folder ~/var/mail/mhe-index/sequence/unseen/ * mh-e.texi 309787 Texinfo /usr/local/src/mh-e/doc/mh-e.texi mh-customize.el 111626 Emacs-Lisp /usr/local/src/mh-e/src/emacs/lisp/mh-e/mh-customize.el TODO 15022 Outline /usr/local/src/mh-e/doc/TODO %* *compilation* 5495 Compilation:exit * *scratch* 41 Lisp Interaction mh-e.el 114953 Emacs-Lisp /usr/local/src/mh-e/src/emacs/lisp/mh-e/mh-e.el devguide.texi92642 Texinfo /usr/local/src/mh-e/htdocs/doc/devguide.texi % *info* 290114 Info * *Messages*1576 Fundamental % *Completions* 199 Completion List * *desktop* 4791 Fundamental *MH-E Log* 0 Fundamental % *Occur*537 Occur % show-+inbox 1011 MH-Show ~/var/mail/inbox/14 -- Bill Wohler [EMAIL PROTECTED] http://www.newt.com/wohler/ GnuPG ID:610BD9AD Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian! If you're passed on the right, you're in the wrong lane. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
scrolling region error in term.el
Symptoms: I run mutt inside emacs using ansi-term. This has always worked fine since emacs 20. When I tried the current CVS for emacs 22 the scrolling would mess up when I had a split screen (I use the mutt option set pager_index_lines=10, which leaves an index at the top and show the messages at the bottom) I took some time to debug it and found the problem. Basically mutt creates a scrolling region at the top of the screen for the index. Scrolling down work fine (cursor is placed at the bottom of the scrolling region, a scroll forward (^[D) is sent, the region scrolls and everything is good. However moving up the list, mutt position the cursor at the top of the scrolling region and a scroll reversed (^[M) is sent. Instead scrolling the lines in the region down, all the lines on the screen are scrolled down. Comparing older versions of term.el the scroll reversed used to be: (emacs 21.4 term.el line 2870:) ((eq char ?M) ;; scroll reversed (term-insert-lines 1) (setq term-terminal-state 0)) and is now: (emacs 22.0.50 term.el line 2895) ((eq char ?M) ;; scroll reversed (terminfo: ri) (term-down -1) (setq term-terminal-state 0)) I changed the (term-down -1) back to (term-insert-lines 1) and then everything works the way it should. term-down has a third argument check-for-scroll, but setting that to true doesn't seem to help either. Hopefully this helps. I do have a test case (captured escape sequences) that illustrate the problem if that is needed. Cheers, Jim In GNU Emacs 22.0.50.2 (i686-pc-linux-gnu, GTK+ Version 2.6.4) of 2005-12-22 on dimaggio X server distributor `The XFree86 Project, Inc', version 11.0.4031 configured using `configure '--with-x-toolkit=gtk'' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: en_US value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: nil locale-coding-system: iso-8859-1 default-enable-multibyte-characters: t Major mode: Info Minor modes in effect: display-time-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-encoding-mode: t utf-translate-cjk-mode: t size-indication-mode: t line-number-mode: t transient-mark-mode: t Recent input: left C-h f1 C-h i C-s b u g s backspace home down down down down down down down down down down down down down down down down down down down down C-return right right return / C-s b u g C-s C-a right right C-return return down down down down down down down down down down down down down down down down down down down down down down down up right right down down down up up C-return return ] escape x r e p o r t - e m a c s - b u g return Recent messages: Loading info... Loading easymenu...done Loading info...done Composing main Info directory...done Mark saved where search started Mark set Mark saved where search started Loading emacsbug... Loading regexp-opt...done Loading emacsbug...done ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: recently introduced bug in minibuffer handling
I tried this now, and the bug does not seem to happen. Does it still fail for you? (defadvice read-file-name (around read-filename-advice activate) Tell `exit-minibuffer' to run a hook. (let ((minibuffer-exit-hook (append minibuffer-exit-hook '(my-minibuffer-hook ad-do-it)) (defun my-minibuffer-hook () Manipulate the minibuffer before exiting it. (goto-char (minibuffer-prompt-end)) (end-of-line) (message current point: %d (point)) (message max point: %d (point-max)) ) Then evaluate (read-file-name foo) for instance, with C-cC-e When you see a prompt, type something at the end. For instance, type ~/.emacs to the end of the stuff that shows in the minibuffer. You will see (in *Messages*) that current point and max point are different! The current point will be at the end of the prompt instead of at the end of what you typed. Now, if you remove (goto-char (minibuffer-prompt-end)) at the beginning of the hook and repeat the experiment then you will see that the current point and the max point are the same. So, something gets messed up. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: loaddefs.el on Windows incomplete
Cc: emacs-pretest-bug@gnu.org From: Ralf Angeli [EMAIL PROTECTED] Date: Mon, 26 Dec 2005 16:56:17 +0100 Thanks for your efforts. I did a fresh checkout into a new directory, ran `configure ...' and while doing `mingw32-make bootstrap' the following error occurred: --8---cut here---start-8--- ./../bin/emacs.exe -batch --no-init-file --no-site-file --multibyte -l autoload \ --eval '(setq find-file-hook nil find-file-suppress-same-file-warnings t)' \ -f w32-batch-update-autoloads D:/software/windows/unix/src/emacs-22.0.50-clean-build/lisp/loaddefs.el . calc calendar emacs-lisp emulation eshell gnus international language mail mh-e net obsolete play progmodes term textmodes url Wrong type argument: symbolp, 0 mingw32-make[1]: *** [autoloads] Error -1 mingw32-make[1]: Leaving directory `D:/software/windows/unix/src/emacs-22.0.50-clean-build/lisp' mingw32-make: *** [bootstrap-gmake] Error 2 --8---cut here---end---8--- A weird error. In order to get a backtrace I set `debug-on-error' to t via the --eval statement above. That means I edited lisp/makefile.w32-in accordingly and ran `configure' again. Interestingly the error did not occur with this change. I tried this both in the directory where the make call failed with the original makefile.w32-in and in a directory which had not seen a make call before. Same results. Still weirder. But see below. Then I tried to run `mingw32-make bootstrap' in a freshly checked out and configured directory including the patch I proposed for lisp/makefile.w32-in and got the same error as above. So the problem doesn't seem to be due to the changes, but to something else. Did you remember to check out the Emacs tree with the -kb switch to the co command? If not, perhaps what you see is due to some EOL-related snafu. Let-binding `debug-on-error' to t made the error vanish again. Now I don't really know where to look for the cause of the error. How about editing lisp/makefile so that Emacs displays its command-line arguments (via `message') before doing anything else? Something like this: ./../bin/emacs.exe -batch --no-init-file --no-site-file --multibyte -l autoload \ --eval '(message %s command-line-args)' --eval '(setq find-file-hook nil find-file-suppress-same-file-warnings t)' \ -f w32-batch-update-autoloads D:/software/windows/unix/src/emacs-22.0.50-clean-build/lisp/loaddefs.el . calc calendar emacs-lisp emulation eshell gnus international language mail mh-e net obsolete play progmodes term textmodes url What does it print, if you try this? If this makes the problem go away, please pay attention to the EOL format of the files that get concatenated into makefile: gmake.defs, the preamble produced by configure.bat, and makefile.w32-in. Anyway, in the directories where the build succeeded I did a `diff -u loaddefs.el ldefs-boot.el' which showed no differences between the files. That's because loaddefs.el never go created, due to the error. Since bootstrap first copies ldefs-boot.el into loaddefs.el, it is expected that they both be identical if the real loaddefs.el fails to be created. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Error during redisplay with included diary file
Please forgive my delay in looking at this bug report. #2 0x08064fad in safe_eval (sexpr=139399637) at xdisp.c:2261 Can you make it get there again, and do f 2 p sexpr pr and show us what that outputs? Also, if you could display the value of mode-line-format, that would lead us to the cause of the problem. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Problem running certain interactive programs in M-x shell in W32
Hello list, I'm geting a weird behavior for some interactive programs in M-x shell and comint buffers in Emacs for W32... for example, if I run lua.exe in a `M-x shell' buffer, I get this; compare with the correct output below. Wrong (comint in W32): [c:\edrx\edrx]lua print(1+2) here I type a ^D Lua 5.0.2 Copyright (C) 1994-2004 Tecgraf, PUC-Rio 3 [c:\edrx\edrx] Process shell finished Right (GNU systems, shell windows in W32, telnet buffers in W32 Emacs connecting to GNU or *NIX systems): [c:\edrx\edrx]lua Lua 5.0.2 Copyright (C) 1994-2004 Tecgraf, PUC-Rio print(1+2) 3 here I type a ^C [c:\edrx\edrx] I have tried the following configurations: Emacsen (with and without -q/-Q): * GNU Emacs 22.0.50.1 (i386-mingw-nt5.0.2195) of 2005-12-18 on W2ONE (Lennart Borgman's build, from http://ourcomments.org/Emacs/EmacsW32.html) * GNU Emacs 22.0.50.1 (i386-mingw-nt5.0.2195) of 2005-06-26 on NONIQPC (From http://nqmacs.sourceforge.net/) Operating systems: * Debian GNU/Linux Sarge * M$-Windows 2000 (in Portuguese) * native shells: command.com/cmd.exe, 4NT (shareware from www.jpsoft.com) * telnet program: plink.exe, from the PuTTY package (option: -telnet); I used it to connect to an IBM thing running AIX Lua (MIT-like license; I tried it because I use it a lot and I know its source reasonably well; versions 5.0.2 and 5.1-beta): * Binaries for W$ downloaded from http://www.cs.princeton.edu/~diego/professional/luasocket/ - http://luaforge.net/projects/luasocket/ * I compiled it from the source in all the other platforms. By the way, I stumbled on that bug while I was trying to understand why tramp was not working on that W$ box... My guess is that the problem with tramp and this problem with the handling of prompts and output in comint might be related, but I don't know enough about tramp's innards to subtantiate this guess - and the debug output that I was able to squeeze from tramp by using (setq tramp-verbose 10) (setq tramp-debug-buffer t) was too short for a bug report... In a few words, if anyone is curious: the default command-line telnet and ftp clients in W$ run well in command.com/cmd.exe/4NT.exe windows (i.e., outside Emacs), but they get stuck when run in M-x shell; and tramp always gives me FATAL ERROR: Network error: Connection refused. Cheers, Edrx, a.k.a. Eduardo Ochs http://angg.twu.net/ ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Can't create loaddefs.el
While chasing down a problem with the setting of url-configuration-directory, I wanted to update loaddefs.el, but look at the error: [EMAIL PROTECTED]:770]$ make autoloads wd=/usr/local/src/mh-e/src/emacs/lisp; subdirs=`(cd $wd; find . -type d -print)`; for file in $subdirs; do case $file in */Old | */RCS | */CVS | */CVS/* | */.* | */.*/* | */=* ) ;; *) wins=$wins $wd/$file ;; esac; done; \ echo Directories: $wins; \ ../src/emacs -batch --no-site-file --multibyte -l autoload --eval '(setq generated-autoload-file /usr/local/src/mh-e/src/emacs/lisp/loaddefs.el)' -f batch-update-autoloads $wins Directories: /usr/local/src/mh-e/src/emacs/lisp/. /usr/local/src/mh-e/src/emacs/lisp/./calc /usr/local/src/mh-e/src/emacs/lisp/./gnus /usr/local/src/mh-e/src/emacs/lisp/./mail /usr/local/src/mh-e/src/emacs/lisp/./calendar /usr/local/src/mh-e/src/emacs/lisp/./emacs-lisp /usr/local/src/mh-e/src/emacs/lisp/./emulation /usr/local/src/mh-e/src/emacs/lisp/./eshell /usr/local/src/mh-e/src/emacs/lisp/./international /usr/local/src/mh-e/src/emacs/lisp/./language /usr/local/src/mh-e/src/emacs/lisp/./mh-e /usr/local/src/mh-e/src/emacs/lisp/./net /usr/local/src/mh-e/src/emacs/lisp/./obsolete /usr/local/src/mh-e/src/emacs/lisp/./play /usr/local/src/mh-e/src/emacs/lisp/./progmodes /usr/local/src/mh-e/src/emacs/lisp/./term /usr/local/src/mh-e/src/emacs/lisp/./textmodes /usr/local/src/mh-e/src/emacs/lisp/./url Wrong type argument: symbolp, 0 make: *** [autoloads] Error 255 I see this change. Related? 2005-12-25 Richard M. Stallman [EMAIL PROTECTED] * eval.c (un_autoload): Expect (0 . OFEATURES) in Vautoload_queue to undo a `provide'. * fns.c (Fprovide): Store (0 . OFEATURES) in Vautoload_queue. -- Bill Wohler [EMAIL PROTECTED] http://www.newt.com/wohler/ GnuPG ID:610BD9AD Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian! If you're passed on the right, you're in the wrong lane. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Can't create loaddefs.el
I tried to debug the problem by adding an --eval '(toggle-debug-on-error)' and loaddefs.el were created! Weird. -- Bill Wohler [EMAIL PROTECTED] http://www.newt.com/wohler/ GnuPG ID:610BD9AD Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian! If you're passed on the right, you're in the wrong lane. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: loaddefs.el on Windows incomplete
Cc: emacs-pretest-bug@gnu.org From: Ralf Angeli [EMAIL PROTECTED] Date: Mon, 26 Dec 2005 16:56:17 +0100 ./../bin/emacs.exe -batch --no-init-file --no-site-file --multibyte -l autoload \ --eval '(setq find-file-hook nil find-file-suppress-same-file-warnings t)' \ -f w32-batch-update-autoloads D:/software/windows/unix/src/emacs-22.0.50-clean-build/lisp/loaddefs.el . calc calendar emacs-lisp emulation eshell gnus international language mail mh-e net obsolete play progmodes term textmodes url Wrong type argument: symbolp, 0 See the thread Re: Can't create loaddefs.el --- this is a new problem, unrelated to the changes I made. Just wait for a while, until this new problem is solved, and then re-sync and try again. Thanks. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
cursor-in-echo-area ignores the default cursor type
After setting the default cursor type to something other than the default block cursor: (setq default-cursor-type 'bar) and using a function that internally sets the variable `cursor-in-echo-area' to non-nil, e.g.: (y-or-n-p prompt: ) or `C-h k' the specified cursor type is ignored and the minibuffer in all these cases displays the block cursor. This is not a critical bug, but it would be nice to fix this if possible. Also the prompt of key-reading commands (like `C-h k') is not highlighted using the `minibuffer-prompt' face. This could be fixed as well. -- Juri Linkov http://www.jurta.org/emacs/ ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: describe-char
This is not reliable way to restore the old output of `describe-char' since the original buffer might be killed or the character at the old position might be deleted, The same holds for most/all other uses of help-setup-xref. So it makes sense to preserve the original contents of the help buffer in other uses too. Now I see a new argument `buf' was added to `describe-char' in CVS. This doesn't work even for normal uses of the help buffer. Clicking on any link in the help buffer created by `describe-char' and going back produces nonsense, because it tries to restore the old contents based on the old position in the new contents of the help buffer. OTOH, I've tested that saving the whole old contents as a string works flawlessly in the help buffer for all links. Are there reasons not to use this solution? -- Juri Linkov http://www.jurta.org/emacs/ ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: font-lock-add-keywords in hi-lock.el
Do you use Hi-Lock (either by putting global-hi-lock-mode in .emacs or by using highlight-regexp or other hi-lock functions)? Not explicitly. Here are my buffers and their modes. I just fired up Gnus with this set and the highlighting was off. Do you know if any of the modes listed below might be triggering the bug? I see nothing to suspect in the buffer list. Could you look at the value of `font-lock-keywords' in the Gnus buffer where highlighting is off. -- Juri Linkov http://www.jurta.org/emacs/ ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: query-replace-regexp and read-only text properties
When I try it, it replaces both instances of `foo '. Are you using the development Emacs? Yes: emacs-version 22.0.50.2. A few days old from HEAD. Strange. Can you debug what's happening inside the loop? It's strange that you can't reproduce it. Perhaps when you type C-M-% on a tty, it is interpreted as M-%. But this bug happens only for regexp replace. The cause of this bug are lines: (and (or match-again ;; MATCH-AGAIN non-nil means we ;; accept an adjacent match. If ;; we don't, move one char to the ;; right. This takes us a ;; character too far at the end, ;; but this is undone after the ;; while-loop. (progn (forward-char 1) that don't take into account the case when a read-only area is adjacent to the next match, and skips it by (forward-char 1). -- Juri Linkov http://www.jurta.org/emacs/ ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
