Re: Compiling with Xorg 7.0
Lars Hansen [EMAIL PROTECTED] wrote: Bill Wohler wrote: By the way, here is what ./configure --with-gtk shows. Note all the none and no items that were previous all yes or something good. I am no expert on this, but here are my experiences of compiling CVS Emacs on Etch: I installed Debian packages libncurses5-dev, libxaw7-dev, xaw3dg-dev, libtiff4-dev, libungif4-dev and libpng12-dev to get good results from ./configure. Yes, I had done that long ago. I also installed libgtk2.0-dev. The problem was that the Xorg 7.0 upgrade removed the one file that ./configure uses to determine that there is a window system *at all*. But the build failed because of problems with the X11 ICE library: ICElib.h was searched in /usr/include/X11/ICE/ but located in /usr/X11R6/include/X11/ICE/ and libICE.a was searched in /usr/lib/ but located in /usr/X11R6/lib/ To fix the problem I made symlinks: # ln -s /usr/X11R6/include/X11/ICE/ /usr/include/X11/ # ln -s /usr/X11R6/lib/libICE.a /usr/lib I don't know if it is an Emacs problem, a Debian problem or an Xorg problem. I never hit that before. As I said previously, I had to install libxt-dev after upgrading to xorg 7.0. What I didn't mention is that the libxt-dev install also forced the installation of libice-dev and libsm-dev, which might be pertinent here. I'd suggest nuking your links before upgrading to 7.0 to keep the installation of xorg-common from failing (which wants to remove lots of stuff from /usr/X11R6). /usr/X11R6 will eventually go away entirely. Anyway, hope this helps someone else in a similar situation. -- Bill Wohler [EMAIL PROTECTED] http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Compiling with Xorg 7.0
I just upgraded to Xorg 7.0 (aka X11R7) over the weekend and now Emacs does not compile. Now that Xorg complies with FHS, the /usr/X11R6 directory is gone. I suspect that Emacs is looking for the various header files and libraries in /usr/X11R6. (Granted, I just updated Emacs too, so something might have changed in Emacs as well.) Has anyone compiled Emacs with Xorg 7.0? Here are some troubled lines in make bootstrap. gcc -c -D_BSD_SOURCE -Demacs -DHAVE_CONFIG_H -DUSE_GTK -I. -I/usr/local/src/mh-e/src/emacs/src -D_BSD_SOURCE -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -g xmenu.c In file included from xmenu.c:130: gtkutil.h:163: error: syntax error before '*' token gtkutil.h:165: warning: 'struct scroll_bar' declared inside parameter list gtkutil.h:165: warning: its scope is only this definition or declaration, which is probably not what you want gtkutil.h:179: warning: 'struct scroll_bar' declared inside parameter list gtkutil.h:192: error: syntax error before '*' token gtkutil.h:194: error: syntax error before 'Display' gtkutil.h:195: error: syntax error before '*' token gtkutil.h:196: error: syntax error before '*' token gtkutil.h:204: error: syntax error before 'Pixmap' xmenu.c: In function 'syms_of_xmenu': xmenu.c:3774: error: 'Smenu_bar_open' undeclared (first use in this function) xmenu.c:3774: error: (Each undeclared identifier is reported only once xmenu.c:3774: error: for each function it appears in.) make[2]: *** [xmenu.o] Error 1 make[2]: Leaving directory `/home/usr.local.src/mh-e/src/emacs/src' make[1]: *** [bootstrap-build] Error 2 make[1]: Leaving directory `/home/usr.local.src/mh-e/src/emacs' make: *** [bootstrap] Error 2 -- Bill Wohler [EMAIL PROTECTED] http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Compiling with Xorg 7.0
By the way, here is what ./configure --with-gtk shows. Note all the none and no items that were previous all yes or something good. Configured for `i686-pc-linux-gnu'. Where should the build process find the source code? /usr/local/src/mh-e/src/emacs What operating system and machine description files should Emacs use? `s/gnu-linux.h' and `m/intel386.h' What compiler should emacs be built with? gcc -g Should Emacs use the GNU version of malloc? yes (Using Doug Lea's new malloc from the GNU C Library.) Should Emacs use a relocating allocator for buffers?yes Should Emacs use mmap(2) for buffer allocation? no What window system should Emacs use?none What toolkit should Emacs use? GTK Where do we find X Windows header files?NONE Where do we find X Windows libraries? NONE Does Emacs use -lXaw3d? no Does Emacs use -lXpm? no Does Emacs use -ljpeg? no Does Emacs use -ltiff? no Does Emacs use -lungif? no Does Emacs use -lpng? no Does Emacs use X toolkit scroll bars? yes ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Compiling with Xorg 7.0
Fixed. I found that configure looks for X11/Intrinsic.h. This file was no longer present on my system, so the upgrade must have relocated it into a separate package, which I found is libxt-dev. After installing the libxt-dev package (on Debian etch), the output of configure looks reasonable and Emacs compiles as we speak (well, as I speak ;-). ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: with-temp-buffer and undo
Bill Wohler [EMAIL PROTECTED] writes: Lars Hansen [EMAIL PROTECTED] wrote: Stefan Monnier wrote: ! `(let ((,temp-buffer (generate-new-buffer *temp*)) !(buffer-undo-list t)) Buffer whose name start with a space have their undo disabled by default. I.e. someone thought of that years ago already, Then my previous patch can be simplified. Any objections? None from me. I've applied it and will let you know how it goes. Thanks. So far so good. Thanks. -- 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: with-temp-buffer and undo
Lars Hansen [EMAIL PROTECTED] wrote: Stefan Monnier wrote: ! `(let ((,temp-buffer (generate-new-buffer *temp*)) !(buffer-undo-list t)) Buffer whose name start with a space have their undo disabled by default. I.e. someone thought of that years ago already, Then my previous patch can be simplified. Any objections? None from me. I've applied it and will let you know how it goes. Thanks. -- 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: Big desktop undo buffer crashes Emacs
Richard Stallman [EMAIL PROTECTED] writes: Every morning for the past weeks, I've had a message in my minibuffer that roughly goes, Desktop undo buffer is 3+ MB, discard? (yes or no). I've been saying yes. This morning, feeling snarky, I said no and Emacs crashed. Could you please provide the precise text of the message? The message includes a buffer name; what is the buffer name? OK, it's back. Here's the message: Buffer `*desktop*' undo info is 3159101 bytes long; discard it? (yes or no) -- 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: Big desktop undo buffer crashes Emacs
Luc Teirlinck [EMAIL PROTECTED] wrote: From my previous reply: I said that it might solve part of your problem. The question is whether the 3M of undo is legitimate. Take a look at what is in that buffer. Does the huge size of the buffer seem legitimate, because there really is that much info to save? I guess that you know that you can produce the buffer using `M-x desktop-save'. Well, the size of the undo info is not necessarily related to the size of the buffer. In my setup, after `M-x desktop-save', I get a *desktop* buffer of size 2943, but my buffer-undo-list (_without_ my patch applied) is very small: (nil (1 . 2944) (t 0 . 0)) I guess that if you created the *desktop* buffer and did `C-h v buffer-undo-list' in it, you would get a really huge *Help* buffer, assuming it would not make your Emacs crash. Right now my desktop buffer is 32 kB; the size of the *Help* buffer you describe is 68 kB. Running desktop-save did not change the size of either (much, the *Help* buffer grew by 200 bytes after running `C-h v buffer-undo-list' again). By the way, the only two desktop-related items in my .emacs are turning on desktop-save-mode (which is probably obvious ;-) and this: (run-at-time 60 300 'desktop-save ~) ;it would be better to catch HUP and ;call desktop-save before exiting I've yet to write the code to catch a kill or quit and run desktop-save on an as-needed basis rather than regularly--maybe someone can volunteer a trick there--but still, why would the buffer go from 68 kB to 3 MB overnight? I think this is the only cron job *I've* set up. Still, I think Stefan might be correct. What does it mean to have undo in the *desktop* buffer in the first place? -- 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: Big desktop undo buffer crashes Emacs
Luc Teirlinck [EMAIL PROTECTED] wrote: Bill Wohler wrote: By the way, the only two desktop-related items in my .emacs are turning on desktop-save-mode (which is probably obvious ;-) and this: (run-at-time 60 300 'desktop-save ~) ;it would be better to catch HUP and ;call desktop-save before exiting The latter was your problem. From `(elisp)Timers': It is usually a bad idea for timer functions to alter buffer contents. When they do, they usually should call `undo-boundary' both before and after changing the buffer, to separate the timer's changes from user commands' changes and prevent a single undo entry from growing to be quite large. So it is no surprise that you accumulated such a large single undo entry. Thanks for the information. Since I don't understand the mechanics of desktop, I have a couple of questions about that. First, I thought desktop-save just saves the buffer to a file. Is it really altering the the *desktop* buffer? Oh, running desktop-save a couple of times shows that it at least updates the Created header field. OK, desktop-save must gather buffer information, write it to *desktop*, and *then* save it to a file. Right? Second, I also don't understand the mechanics of undo very well. I was under the impression that undo-boundary only grouped a set of changes into a single undo entry. As I sit here writing, only a limited amount of changes are saved and at some point the oldest undo information will be discarded. How is the timer different? Interesting, as I typed this, the timer had run a couple of times (I was thinking and trying to understand desktop and undo). I re-ran `C-h v buffer-undo-list' a few times too. It just produced buffers with only 35 kB, not 68 kB. Right now my desktop buffer is 32 kB; So that is approximately 32 kB every five minutes. After eight hours, you exceed 3M. Anyway, my patch, or disabling undo, completely gets rid of this problem. So, which one should I apply? Before I fix my timer ;-). If the *desktop* buffer is ephemeral and recreated when desktop-save is run, it seems that disabling undo is the proper course of action. Otherwise, preserving undo while protecting against abuse would be wise. What do you think? -- 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: Big desktop undo buffer crashes Emacs
Luc Teirlinck [EMAIL PROTECTED] wrote: I now realize that *desktop* is not a file visiting buffer, so it does not matter if people mess it up. Thus one can indeed just disable undo rather than applying the patch I proposed. But that user visible *desktop* buffer is confusing, especially if the user also has a buffer visiting his desktop-base-file-name, since the two buffers are identical. Is there any reason not to rename *desktop* to *desktop (with a leading space) and kill it after it is written to disk? Is there any reason to keep this buffer hanging around consuming some memory and being user visible? Thanks, Luc. This exact thought coursed through my mind. Would Mr. Desktop please chime in? -- 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: Big desktop undo buffer crashes Emacs
Richard Stallman [EMAIL PROTECTED] wrote: Every morning for the past weeks, I've had a message in my minibuffer that roughly goes, Desktop undo buffer is 3+ MB, discard? (yes or no). I've been saying yes. This morning, feeling snarky, I said no and Emacs crashed. Could you please provide the precise text of the message? The message includes a buffer name; what is the buffer name? I haven't seen the prompt in a couple of days. Could a recent update have suppressed it? -- 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
More safe local variables
Emacs complained about these local variables after a fresh update (it's been a couple of weeks): ;; no-byte-compile: t ;; indent-tabs-mode: nil I thought these had been made safe. -- 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: Big desktop undo buffer crashes Emacs
Richard Stallman [EMAIL PROTECTED] wrote: Every morning for the past weeks, I've had a message in my minibuffer that roughly goes, Desktop undo buffer is 3+ MB, discard? (yes or no). I've been saying yes. This morning, feeling snarky, I said no and Emacs crashed. Could you please provide the precise text of the message? The message includes a buffer name; what is the buffer name? Weird, a copy of the message was *not* saved in the *Messages* buffer. I'll write it down on a piece of paper tomorrow. -- 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: Big desktop undo buffer crashes Emacs
Luc Teirlinck [EMAIL PROTECTED] wrote: Bill Wohler wrote: Weird, a copy of the message was *not* saved in the *Messages* buffer. It is not a message, but a yes-or-no-p prompt. Oh, right. Duh. Not the first time I've said something stupid before coffee. Definitely not a morning person. Will transcribe the message tomorrow. -- 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: tool-bar-setup overwrites local tool-bar-map
Richard Stallman [EMAIL PROTECTED] wrote: To see what should have happened: emacs22 -Q M-x tool-bar-mode Note how Preferences and Help icons are present. M-x info Note how Preferences and Help icons are absent. In what sense is that what should have happened? I do not follow. You get the tool bar as the info package had intended. Shouldn't the Preferences and Help icons always be present? Arguably yes, but their function is context-dependent. For example, the MH-E package defines the actions as mh-tool-bar-customize and mh-tool-bar-folder-help or mh-tool-bar-letter-help where the default actions are customize and help. With the current tool-bar code, the behavior is inconsistent. If one runs tool-bar-mode first, and then MH-E, one sees the one pair of Preferences/Help buttons (the ones defined by MH-E). If vice-versa, one sees *two* pairs of Preferences/Help buttons (the ones defined by MH-E plus the ones defined by tool-bar). Similarly, if one runs tool-bar-mode first, and then info, one does not see the pair of Preferences/Help buttons since the info package does not define them. If vice-versa, one sees the pair of Preferences/Help buttons defined by tool-bar. Does that help clear things up? What are you asking us to do? My patch makes the tool-bar's behavior consistent. It prevents the default tool bar from interfering with the mode's tool bar if tool-bar-mode is run after the mode has been initialized. I just wanted a review and a Please check it in before checking it in. Perhaps Nick Roberts? Here it is again. Index: tool-bar.el === RCS file: /cvsroot/emacs/emacs/lisp/tool-bar.el,v retrieving revision 1.5 diff -u -u -r1.5 tool-bar.el --- tool-bar.el 6 Feb 2006 14:33:35 - 1.5 +++ tool-bar.el 30 Apr 2006 18:21:10 - @@ -267,14 +267,16 @@ ;;(tool-bar-add-item-from-menu 'compose-mail mail/compose) (tool-bar-add-item-from-menu 'print-buffer print) - (tool-bar-add-item preferences 'customize 'customize -:help Edit preferences (customize)) + (tool-bar-local-item preferences 'customize 'customize + (default-value 'tool-bar-map) + :help Edit preferences (customize)) - (tool-bar-add-item help (lambda () - (interactive) - (popup-menu menu-bar-help-menu)) -'help -:help Pop up the Help menu) + (tool-bar-local-item help (lambda () +(interactive) +(popup-menu menu-bar-help-menu)) + 'help + (default-value 'tool-bar-map) + :help Pop up the Help menu) ) (provide 'tool-bar) -- 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: Big desktop undo buffer crashes Emacs
Bill Wohler [EMAIL PROTECTED] writes: Every morning for the past weeks, I've had a message in my minibuffer that roughly goes, Desktop undo buffer is 3+ MB, discard? (yes or no). I've been saying yes. This morning, feeling snarky, I said no and Emacs crashed. I said no to that question twice this morning, and Emacs did not crash. What is this Desktop undo buffer by the way? And why does Emacs keep asking me this question? I'd still like to know the answer to these questions. Thanks. -- 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: tool-bar-setup overwrites local tool-bar-map
Richard Stallman [EMAIL PROTECTED] writes: You can reproduce with emacs22 -Q --xrm Emacs.toolBar:0. Is this a corner-case we wish to fix? I think so. We should fix every case, except when the fix is so hard or risky that we decide to let it go. My (last) patch still seems to be working well for me. Is anyone else observing this problem that can verify the patch? If not, does anyone object if I try checking it in so we can see if it causes problems for others? (Does anyone on this list use tool bars? ;-) -- 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: tool-bar-setup overwrites local tool-bar-map
Nick Roberts [EMAIL PROTECTED] wrote: emacs22 -Q M-x info M-x tool-bar-mode Note how Preferences and Help icons are present. This doesn't make sense to me. If you start with -Q then doesn't tool-bar-mode tool-bar-mode turn the tool bar *off*? Nick, you bring up a good point. I have Emacs.toolBar: 0 in my .Xresources file to avoid the frame resizing that happens if you just customize tool-bar-mode to nil. If I set Emacs.toolBar: 1, then I don't see the problem. You can reproduce with emacs22 -Q --xrm Emacs.toolBar:0. Is this a corner-case we wish to fix? I think so. -- 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: no-byte-compile no longer considered safe?
Richard Stallman [EMAIL PROTECTED] writes: I guess a simper way to do it is to provide a var that says set all the safe vars and ignore the others. I hope I never simper, but I implemented your suggestion. Thanks, it appears to have fixed the problem. The files that shouldn't be byte-compiled are no longer byte-compiled. -- 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: no-byte-compile no longer considered safe?
Richard Stallman [EMAIL PROTECTED] writes: Should no-byte-compile be marked as a safe variable, It already is, since a month ago. But the problem could still be related to that. Does Emacs currently ask any questions when you visit any of these files? Ah, now I see what happened and I found the bug. I was actually being asked for another variable in the same Local Variables stanza. If you add the following to a file, make recompile will compile it: ;; Local Variables: ;; no-byte-compile: t ;; url-unreserved-chars: nil ;; End -- 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
no-byte-compile no longer considered safe?
An MH-E user has reported that a few of the MH-E files which MUST NOT be compiled were compiled after a recent CVS Emacs update. I've noticed this behavior too after I updated. Unfortunately, the compilation of these files causes mysterious bugs in MH-E (which is why we set no-byte-compile to t in the local variables stanza). When I fired up Emacs recently, I noticed that I was prompted for several of my local variables. I imagine that the safe variable code that has been discussed here was implemented. Related? Should no-byte-compile be marked as a safe variable, or is there something the MH-E package should be doing differently now? -- 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: emacs-unicode-2: bootstrap failed due to recent mh-e changes
Zhang Wei [EMAIL PROTECTED] writes: Compiling /home/brep/emacs-source/emacs-unicode-2/lisp/./mh-e/mh-e.el In toplevel form: mh-e/mh-e.el:997:1:Error: Symbol's function definition is void: mh-strip-package-version make[2]: *** [compile] Error 1 make[2]: Leaving directory `/home/brep/emacs-source/emacs-unicode-2/lisp' make[1]: *** [bootstrap-build] Error 2 make[1]: Leaving directory `/home/brep/emacs-source/emacs-unicode-2' make: *** [bootstrap] Error 2 Fixed. Apologies. If an update doesn't resolve the problem, please remove lisp/mh-e/*.elc and try again. -- 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: emacs-unicode-2: bootstrap failed due to recent mh-e changes
Luc Teirlinck [EMAIL PROTECTED] wrote: Bill Wohler wrote: If an update doesn't resolve the problem, please remove lisp/mh-e/*.elc and try again. All of that is apparently not sufficient to solve the problem. Still same error message: Compiling /home/teirllm/emacscvsdir/emacs/lisp/./mh-e/mh-e.el In toplevel form: mh-e/mh-e.el:997:1:Error: Symbol's function definition is void: mh-strip-package-version make[2]: *** [compile] Error 1 make[2]: Leaving directory `/home/teirllm/emacscvsdir/emacs/lisp' make[1]: *** [bootstrap-build] Error 2 make[1]: Leaving directory `/home/teirllm/emacscvsdir/emacs' make: *** [bootstrap] Error 2 I do not understand this. If you remove mh-e/*.elc, it compiles. If you just touch mh-e/mh-e.el and compile it fails. I found that making mh-strip-package-version a macro fixes the error (which I just checked in). If someone would like to explain why this is so, I would listen eagerly. Is this fixing the problem, or merely masking the symptoms? Color me baffled by the compiler (again). -- 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: State button in Customize is not a button
Drew Adams [EMAIL PROTECTED] writes: The State button in Customize is not a button but a pulldown list (menu). Your observation applies to the Value Menu as well. Sounds like changing the text of the State menu from State to State Menu would be a good choice as long as the widget still looks like a button. In general, however, pulldown menus are not a good UI idea. Disagree in general. They are fine in menu bars and context menus. Because it is too easy to not notice that they are menus (i.e represent choices). I agree. The menus should not look like buttons. I am at a loss of how to make a standalone menu though as menus are usually associated with menu bars. And these are menus, not comboboxes, since they perform actions, not just represent choices. Now that I think of it, the Value Menu is not a menu, but a combobox. Oy, we probably should postpone creating different widgets for menus and comboboxes until after the release. It is a bad idea for the closed state of a menu to represent one of the possible menu choices. True, but you'd use a combobox widget in this case and it doesn't apply to the State menu anyway. -- 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: font-lock-add-keywords in hi-lock.el
Bill Wohler [EMAIL PROTECTED] writes: Bill Wohler [EMAIL PROTECTED] writes: signal(error (Font-lock trying to use keywords before setting them up)) error(Font-lock trying to use keywords before setting them up) font-lock-compile-keywords(nil t) font-lock-fontify-keywords-region(1 81 nil) font-lock-default-fontify-region(1 80 nil) font-lock-fontify-region(1 80) mh-add-sequence-notation(1 t) ... I think the bug is in font-lock, not in MH-E. I see that font-lock-default-fontify-buffer calls font-lock-set-defaults. It seems that font-lock-fontify-region is a perfectly good entry point to font-lock so that font-lock-default-fontify-region might as well call font-lock-set-default too. When I added a call to font-lock-set-default to to the top of font-lock-default-fontify-region, the bug went away. Does this sound right? Are the modes responsible for calling this seemingly internal function. It certainly isn't documented. I do see that dig.el, sh-script.el, and vhdl-mode.el call this function, but maybe these were added to work around this bug. I'd appreciate it if someone who was more familiar with this code inserted the call to font-lock-set-default in the correct place (I had just inserted it blindly at the top). Also, it would be a good idea to check the other functions and see if there are other entry points that are missing this call. There is one inconsistent call to font-lock-set-default. font-lock-fontify-block checks for (not font-lock-mode) first before calling font-lock-set-default. The rest just go ahead and call font-lock-set-default. Maybe all these calls to font-lock-set-defaults can be replaced with a single call to font-lock-set-defaults in font-lock-compile-keywords to replace this code: (if (not font-lock-set-defaults) ;; This should never happen. But some external packages sometimes ;; call font-lock in unexpected and incorrect ways. It's important to ;; stop processing at this point, otherwise we may end up changing the ;; global value of font-lock-keywords and break highlighting in many ;; other buffers. (error Font-lock trying to use keywords before setting them up)) OK, that's better, thanks! I still need to check the other calls on the stack, but mh-visit-folder contains this: (make-local-variable 'font-lock-defaults) (setq font-lock-defaults '(mh-folder-font-lock-keywords t)) Is this the usual way of injecting one's keywords? Will also RTFM. The manual seems to indicate that setting font-lock-defaults in this fashion is exactly the right way to proceed. It also implies that font-lock-defaults is already buffer local so we should be able to delete the make-local-variable call above, right? I haven't gotten any replies to this message. I've been running the following patch for the past week which has fixed the Gnus fontification bug. May I check it in? Index: font-lock.el === RCS file: /cvsroot/emacs/emacs/lisp/font-lock.el,v retrieving revision 1.290 diff -u -r1.290 font-lock.el --- font-lock.el3 Jan 2006 17:00:35 - 1.290 +++ font-lock.el5 Jan 2006 22:50:10 - @@ -1028,6 +1028,8 @@ a very meaningful entity to highlight.) (defun font-lock-default-fontify-region (beg end loudly) + ;; Make sure we have the right `font-lock-keywords' etc. + (font-lock-set-defaults) (save-buffer-state ((parse-sexp-lookup-properties (or parse-sexp-lookup-properties font-lock-syntactic-keywords)) -- 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: font-lock-add-keywords in hi-lock.el
Stefan Monnier [EMAIL PROTECTED] wrote: I haven't gotten any replies to this message. Sorry I didn't reply, but I did install a patch that does something similar to what you suggest. Now I see it. Thanks. I'll take out my patch and run with yours. I was thinking along the same lines too, but was too timid to go up a function call. -- 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: font-lock-add-keywords in hi-lock.el
Richard M. Stallman [EMAIL PROTECTED] wrote: Is this the usual way of injecting one's keywords? You don't want to start injecting keywords. What if you got addicted to them? I'd probably get to know font-lock a lot more than I do now. -- 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: font-lock-add-keywords in hi-lock.el
Stefan Monnier [EMAIL PROTECTED] writes: Is that enough information to find the culprit, or is there a watch I can put on the global value of font-lock-keywords which will print a stacktrace or enter the debugger when it is changed? ... Before fixing it, it would be useful to know how it gets called. In the buffer list you sent earlier there is the *Occur* buffer. Do you remember on what buffer you called `occur'? Very likely `occur' forced fontification on a non-font-lock buffer. I've added a sanity check in font-lock-compile-keywords which should at least catch the offenders before they wreak havoc (hopefully the offenders are not font-lock itself). Thanks. I'll have to try that. In the meantime, I can now reproduce the problem! And, it's uh, in MH-E :-(. emacs -Q C-x b foo RET M-: font-lock-keywords RET = nil C-x k RET M-x mh-rmail C-x b foo RET M-: font-lock-keywords RET = (t nil) (but only if you have unseen messages in +inbox) C-x k RET F v +some-folder RET(mh-visit-folder, must have at least one message) C-x b foo RET M-: font-lock-keywords RET = (t nil) Interestingly, I found that if you kill a folder's buffer and then revisit that folder, this problem does not reappear. But choose a folder that you haven't yet visited with at least one message, and it does. Can you guys take a quick peek and see if you see anything obvious? If not, I'll debug this. If you have GNU mailutils or nmh installed, and you can get a message in +some-folder you should be able to perform the above steps. (Hint: the first chapter of the MH-E manual--even the old one that is currently in Emacs--is a tutorial which will help you do this.) I've opened an MH-E bug #1393879 on this: https://sourceforge.net/tracker/index.php?func=detailaid=1393879group_id=13357atid=113357 -- 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: font-lock-add-keywords in hi-lock.el
Bill Wohler [EMAIL PROTECTED] writes: Can you guys take a quick peek and see if you see anything obvious? If not, I'll debug this. I didn't see anything obvious, but I'm not intimately familiar with the font-lock stuff. mh-visit-folder contains this: (make-local-variable 'font-lock-defaults) (setq font-lock-defaults '(mh-folder-font-lock-keywords t)) Is this the usual way of injecting one's keywords? -- 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: font-lock-add-keywords in hi-lock.el
Stefan Monnier [EMAIL PROTECTED] wrote: Is that enough information to find the culprit, or is there a watch I can put on the global value of font-lock-keywords which will print a stacktrace or enter the debugger when it is changed? ... Before fixing it, it would be useful to know how it gets called. In the buffer list you sent earlier there is the *Occur* buffer. Do you remember on what buffer you called `occur'? Very likely `occur' forced fontification on a non-font-lock buffer. I've added a sanity check in font-lock-compile-keywords which should at least catch the offenders before they wreak havoc (hopefully the offenders are not font-lock itself). This error was not triggered when I visited a folder in MH-E. Have you re-dumped Emacs in the mean time. font-lock is now preloaded. Nope. Thanks for the reminder. Dumping... Running... signal(error (Font-lock trying to use keywords before setting them up)) error(Font-lock trying to use keywords before setting them up) font-lock-compile-keywords(nil t) font-lock-fontify-keywords-region(1 81 nil) font-lock-default-fontify-region(1 80 nil) font-lock-fontify-region(1 80) mh-add-sequence-notation(1 t) mh-notate-user-sequences() mh-regenerate-headers((all)) mh-scan-folder(+tmp/laptops all) mh-visit-folder(+tmp/laptops all) call-interactively(mh-visit-folder) OK, that's better, thanks! I still need to check the other calls on the stack, but mh-visit-folder contains this: (make-local-variable 'font-lock-defaults) (setq font-lock-defaults '(mh-folder-font-lock-keywords t)) Is this the usual way of injecting one's keywords? Will also RTFM. -- 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: font-lock-add-keywords in hi-lock.el
Bill Wohler [EMAIL PROTECTED] writes: signal(error (Font-lock trying to use keywords before setting them up)) error(Font-lock trying to use keywords before setting them up) font-lock-compile-keywords(nil t) font-lock-fontify-keywords-region(1 81 nil) font-lock-default-fontify-region(1 80 nil) font-lock-fontify-region(1 80) mh-add-sequence-notation(1 t) ... I think the bug is in font-lock, not in MH-E. I see that font-lock-default-fontify-buffer calls font-lock-set-defaults. It seems that font-lock-fontify-region is a perfectly good entry point to font-lock so that font-lock-default-fontify-region might as well call font-lock-set-default too. When I added a call to font-lock-set-default to to the top of font-lock-default-fontify-region, the bug went away. Does this sound right? Are the modes responsible for calling this seemingly internal function. It certainly isn't documented. I do see that dig.el, sh-script.el, and vhdl-mode.el call this function, but maybe these were added to work around this bug. I'd appreciate it if someone who was more familiar with this code inserted the call to font-lock-set-default in the correct place (I had just inserted it blindly at the top). Also, it would be a good idea to check the other functions and see if there are other entry points that are missing this call. There is one inconsistent call to font-lock-set-default. font-lock-fontify-block checks for (not font-lock-mode) first before calling font-lock-set-default. The rest just go ahead and call font-lock-set-default. Maybe all these calls to font-lock-set-defaults can be replaced with a single call to font-lock-set-defaults in font-lock-compile-keywords to replace this code: (if (not font-lock-set-defaults) ;; This should never happen. But some external packages sometimes ;; call font-lock in unexpected and incorrect ways. It's important to ;; stop processing at this point, otherwise we may end up changing the ;; global value of font-lock-keywords and break highlighting in many ;; other buffers. (error Font-lock trying to use keywords before setting them up)) OK, that's better, thanks! I still need to check the other calls on the stack, but mh-visit-folder contains this: (make-local-variable 'font-lock-defaults) (setq font-lock-defaults '(mh-folder-font-lock-keywords t)) Is this the usual way of injecting one's keywords? Will also RTFM. The manual seems to indicate that setting font-lock-defaults in this fashion is exactly the right way to proceed. It also implies that font-lock-defaults is already buffer local so we should be able to delete the make-local-variable call above, right? -- 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: font-lock-add-keywords in hi-lock.el
Stefan Monnier [EMAIL PROTECTED] writes: signal(error (Font-lock trying to use keywords before setting them up)) error(Font-lock trying to use keywords before setting them up) font-lock-compile-keywords(nil t) font-lock-fontify-keywords-region(1 81 nil) font-lock-default-fontify-region(1 80 nil) font-lock-fontify-region(1 80) mh-add-sequence-notation(1 t) So it looks like the problem is that you call font-lock-fontify-region without first setting up font-lock variables (e.g. by calling font-lock-mode or font-lock-set-defaults). The manual doesn't mention either font-lock-fontify-buffer or font-lock-fontify-region. Is that because the manual is incomplete or because we are using font-lock in an undocumented way? Nonetheless, if font-lock-default-fontify-buffer calls font-lock-set-defaults, it seems that font-lock-default-fontify-region should as well, thereby fixing the problem. -- 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
Richard M. Stallman [EMAIL PROTECTED] wrote: I think I fixed this. Does it work now? Yes, thanks! -- 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: 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
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: font-lock-add-keywords in hi-lock.el
Romain Francoise [EMAIL PROTECTED] writes: Bill Wohler [EMAIL PROTECTED] writes: Was this patch expected to fix the broken Gnus highlighting me and others have reported? No, we fixed this one on November 24th. This bug (Gnus losing its highlighting) reared its ugly head again a couple of times in the past two days for me. -- 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
url-cookie-file noise
In the last few weeks, I've started to see the following message in the minibuffer at odd intervals: Cookies file /home/wohler/.url/cookies (see variable `url-cookie-file') is unwritable. I'm not using this package explicitly. Either it, or the package using it, should be ensuring that the url environment is set up correctly without user intervention. In this particular case, I assume that means creating ~/.url (which does not exist on my system). The last few entries in the url ChangeLog are as follows. Hmmm, timer sure sounds suspicious... 2005-12-07 Klaus Straubinger [EMAIL PROTECTED] (tiny change) * url-cookie.el (url-cookie-save-interval): Simplify. (url-cookie-setup-save-timer): Simplify. 2005-12-04 Klaus Straubinger [EMAIL PROTECTED] (tiny change) * url-history.el (url-history-list): Var deleted. (url-history-save-interval): Simplify. (url-history-setup-save-timer): Simplify. 2005-12-01 Kim F. Storm [EMAIL PROTECTED] * url-history.el (url-history-track): Fix last change. 2005-12-01 Klaus Straubinger [EMAIL PROTECTED] (tiny change) * url-history.el (url-history-track): Call url-history-setup-save-timer in :set function. :type allows three alternatives. (url-history-setup-save-timer): Test url-history-track. * url.el (url-retrieve): Test url-history-track. -- 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: font-lock-add-keywords in hi-lock.el
Romain Francoise [EMAIL PROTECTED] wrote: Bill Wohler [EMAIL PROTECTED] writes: Was this patch expected to fix the broken Gnus highlighting me and others have reported? No, we fixed this one on November 24th. That explains why I haven't seen the problem in a week ;-). Thanks. -- 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: font-lock-add-keywords in hi-lock.el
Juri Linkov [EMAIL PROTECTED] writes: hi-lock-mode breaks existing highlighting when its regexps cover areas highlighted by standard font-lock keywords (non-syntactic). This is especially undesirable on large highlighted areas like outline headings etc. ... A patch below... Was this patch expected to fix the broken Gnus highlighting me and others have reported? After running M-x font-lock-fontify-buffer in the *Group* buffer (which I think is a recipe that was posted here), the highlighting goes away. It also goes away in subsequent *Summary* and *Article* buffers! By the way, I haven't noticed the broken highlighting in the last week. Maybe something got fixed. Maybe I've gotten lucky. I don't know. -- 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: find-file sometimes doesn't
Stefan Monnier [EMAIL PROTECTED] wrote: Interesting. But the above solution still has the following problem: pop-to-buffer may create a new frame, in which case the save-window-excursion won't be enough. Basically, we need to tell vc-do-command not to call pop-to-buffer. I'll install a patch for it, thanks. Thank you. -- 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: find-file sometimes doesn't
Stefan Monnier [EMAIL PROTECTED] wrote: But the above solution still has the following problem: pop-to-buffer may create a new frame, in which case the save-window-excursion won't be enough. Basically, we need to tell vc-do-command not to call pop-to-buffer. I'll install a patch for it, thanks. Thank you. Does the patch below solve the problem? Yes, thanks. -- 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: find-file sometimes doesn't
Stefan Monnier [EMAIL PROTECTED] wrote: In the last week, sometimes maybe 1 in 20 times, C-x C-f (find-file) RET won't find the given file. However, the symptom is that if I'm editing buffer foo, and run find-file to open file bar, instead of getting two equally-sized windows containing foo and bar, I get two foo windows, one of which is only three lines high. Is this reproducible? Yes! If you find a file that is under revision control that you do not have permission to edit, you get the following: I can't reproduce it here. Is it true for any revision control system, or did you use a specific one? I'm using Subversion. I don't have any ready examples from other systems at the moment. However, keep reading. If so, can you please debug it? Not completely. I tracked the problem down to find-file-name-handler setting buffer-file-name to nil (maybe that's enough info to remind someone of a change they made in the past couple of weeks). Here's the stack at that time: Le code of find-file-name-handler doesn't seem to leave much possibility for buffer-file-name to be set to nil. What makes you think that's where the variable is nil'd ? Twilight zone. I could have sworn that `e' of buffer-file-name before the call showed the file name and an `e' of buffer-file-name after the call showed nil but now I find that it was a different problem which I was able to fix. Here is the patch which I just checked in and ChangeLog entry which explains it. Please review. 2005-12-12 Bill Wohler [EMAIL PROTECTED] * vc-svn.el (vc-svn-registered): Fix problem of visiting non-writable Subversion-controlled files by saving window configuration before calling vc-do-command. vc-do-command calls pop-to-buffer on error which is unexpected during registration. Index: vc-svn.el === RCS file: /cvsroot/emacs/emacs/lisp/vc-svn.el,v retrieving revision 1.22 diff -u -r1.22 vc-svn.el --- vc-svn.el 14 Nov 2005 04:33:03 - 1.22 +++ vc-svn.el 13 Dec 2005 00:42:59 - @@ -114,13 +114,18 @@ (file-name-directory file))) (with-temp-buffer (cd (file-name-directory file)) - (condition-case nil - (vc-svn-command t 0 file status -v) - ;; Some problem happened. E.g. We can't find an `svn' executable. -;; We used to only catch `file-error' but when the process is run on -;; a remote host via Tramp, the error is only reported via the -;; exit status which is turned into an `error' by vc-do-command. - (error nil)) +(condition-case nil +;; Save configuration since vc-do-command calls pop-to-buffer on +;; error (such as visiting a Subversion-controlled file that you +;; don't have permission to edit). This causes later problems +;; during registration. +(save-window-excursion + (vc-svn-command t 0 file status -v)) + ;; Some problem happened. E.g. We can't find an `svn' executable. + ;; We used to only catch `file-error' but when the process is run on + ;; a remote host via Tramp, the error is only reported via the + ;; exit status which is turned into an `error' by vc-do-command. + (error nil)) (vc-svn-parse-status t) (eq 'SVN (vc-file-getprop file 'vc-backend) -- 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: find-file sometimes doesn't
Richard M. Stallman [EMAIL PROTECTED] writes: In the last week, sometimes maybe 1 in 20 times, C-x C-f (find-file) RET won't find the given file. However, the symptom is that if I'm editing buffer foo, and run find-file to open file bar, instead of getting two equally-sized windows containing foo and bar, I get two foo windows, one of which is only three lines high. Is this reproducible? Yes! If you find a file that is under revision control that you do not have permission to edit, you get the following: Debugger entered--Lisp error: (wrong-type-argument stringp nil) file-symlink-p(nil) vc-find-file-hook() run-hooks(find-file-hook) after-find-file(nil t) find-file-noselect-1(#buffer interfaces /etc/network/interfaces nil nil /etc/network/interfaces (80445 769)) find-file-noselect(/etc/network/interfaces nil nil t) find-file(/etc/network/interfaces t) call-interactively(find-file) Oddly, this alternates. The next time you use C-x C-f on the same file, it succeeds. Kill the buffer and find it again and it fails. The use of revert-buffer on such a read-only buffer fails in the same way every time. If so, can you please debug it? Not completely. I tracked the problem down to find-file-name-handler setting buffer-file-name to nil (maybe that's enough info to remind someone of a change they made in the past couple of weeks). Here's the stack at that time: Debugger entered--returning value: nil find-file-name-handler(/etc/network/interfaces vc-registered) * vc-registered(/etc/network/interfaces) * vc-backend(/etc/network/interfaces) * byte-code(... * vc-find-file-hook() run-hooks(find-file-hook) after-find-file(nil nil t t nil) revert-buffer(t) call-interactively(revert-buffer) execute-extended-command(nil) call-interactively(execute-extended-command) find-file-name-handler is down in C which is beyond my ability to debug. But the recipe is: 1. emacs -q 2. Visit a file that is under revision control and owned by someone else (in my case /etc/network/interfaces is owned by `root' and is checked into Subversion and I'm trying to edit it as `wohler'). 3. If that doesn't bomb out, revert-buffer will. I hope that provides enough info for someone else to debug this readily. -- 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: find-file sometimes doesn't
Richard M. Stallman [EMAIL PROTECTED] wrote: In the last week, sometimes maybe 1 in 20 times, C-x C-f (find-file) RET won't find the given file. However, the symptom is that if I'm editing buffer foo, and run find-file to open file bar, instead of getting two equally-sized windows containing foo and bar, I get two foo windows, one of which is only three lines high. If you delete the second window and try again, does it fail again? It's very sporadic. So far, the second time I use find-file on the file, it succeeds normally. Coincidentally in the last week, I've noticed that when Emacs starts, instead of the splash screen taking up the entire frame, the last buffer edited (I use desktop) appears, with a small GNU Emacs window at the bottom saying to use C-l to start editing. The coincidence is that this small window is also three lines and is accompanied by the same light show as I mentioned above. Is this reproducible? If so, can you please debug it? As soon as I can reproduce it, I will. Perhaps it is tickled by something odd in the desktop file, much like some buffer causes the Gnus buffers not to highlight properly (at least we know in that case it's a buffer that uses hilite (?)). -- 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: Re: SPC no longer completes when minibuffer-completing-file-name is t
Stefan Monnier [EMAIL PROTECTED] wrote: Emacs now inserts a space when trying to complete an MH-E folder (for example, when visiting a folder or refiling a message). Not when trying to complete: when hitting SPC. It used to be that SPC tried to complete, but now (when entering file names), it doesn't complete any more. Use TAB. Thanks. At first I was incredulous to hear it but then I found this in NEWS which explains the rationale. ** When Emacs prompts for file names, SPC no longer completes the file name. This is so filenames with embedded spaces could be input without the need to quote the space with a C-q. The underlying changes in the keymaps that are active in the minibuffer are described below under New keymaps for typing file names. In your opinion, should we be setting minibuffer-completing-file-name to t when calling completing-read to complete mail folders? I suspect that we do since folders are essentially files and can also contain spaces (I just checked--MH doesn't appear to barf if you create a folder with spaces). If not, what would we need to do to get the proper character to highlight? If minibuffer-completing-file-name is nil, then the highlighting is one character to the right of where it should be. -- 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: SPC no longer completes when minibuffer-completing-file-name is t
Stefan Monnier [EMAIL PROTECTED] wrote: In your opinion, should we be setting minibuffer-completing-file-name to t when calling completing-read to complete mail folders? Yes. It's also obeyed by partial-completion-mode. Thank you. I'll update the MH-E manual accordingly. -- 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
find-file sometimes doesn't
In the last week, sometimes maybe 1 in 20 times, C-x C-f (find-file) RET won't find the given file. However, the symptom is that if I'm editing buffer foo, and run find-file to open file bar, instead of getting two equally-sized windows containing foo and bar, I get two foo windows, one of which is only three lines high. There is a slight light show or noticeable flicker of buffers as if someone had forgotten to use save-excursion. There aren't any clues in the *Messages* buffer. Has anyone else seen this? Sorry, I not yet have a recipe, but will provide more details when and if I get them. Coincidentally in the last week, I've noticed that when Emacs starts, instead of the splash screen taking up the entire frame, the last buffer edited (I use desktop) appears, with a small GNU Emacs window at the bottom saying to use C-l to start editing. The coincidence is that this small window is also three lines and is accompanied by the same light show as I mentioned above. -- 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
(no subject)
Emacs now inserts a space when trying to complete an MH-E folder (for example, when visiting a folder or refiling a message). Could this change be responsible? 2005-12-06 Stefan Monnier [EMAIL PROTECTED] * minibuf.c (keys_of_minibuf): Just unbind SPC in Vminibuffer_local_filename_completion_map rather than forcing it explicitly to the same binding as the global map. In the code below, if I comment out the setting of minibuffer-completing-file-name, the space again performs completion and I can't discern any difference in the completion. What is the effect of setting minibuffer-completing-file-name? Is it kosher? Do any of the MH-E developers know why we do this? I'm not sure if the MH-E code is broken and was living on borrowed time or whether a recent change broke Emacs. Please advise. (defun mh-folder-completing-read (prompt default allow-root-folder-flag) Read folder name with PROMPT and default result DEFAULT. If ALLOW-ROOT-FOLDER-FLAG is non-nil then \+\ is allowed to be a folder name corresponding to `mh-user-path'. (mh-normalize-folder-name (let ((minibuffer-completing-file-name t) (completion-root-regexp ^[+/]) (minibuffer-local-completion-map mh-folder-completion-map) (mh-allow-root-folder-flag allow-root-folder-flag)) (completing-read prompt 'mh-folder-completion-function nil nil nil 'mh-folder-hist default)) t)) -- 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
SPC no longer completes when minibuffer-completing-file-name is t
[Resending without a Mail-Followup-To and with a Subject :-(. If you responded to the previous copy, you may have to resend it to emacs-pretest-bug@gnu.org if this address wasn't a recipient.] Emacs now inserts a space when trying to complete an MH-E folder (for example, when visiting a folder or refiling a message). Could this change be responsible? 2005-12-06 Stefan Monnier [EMAIL PROTECTED] * minibuf.c (keys_of_minibuf): Just unbind SPC in Vminibuffer_local_filename_completion_map rather than forcing it explicitly to the same binding as the global map. In the code below, if I comment out the setting of minibuffer-completing-file-name, the space again performs completion and I can't discern any difference in the completion. What is the effect of setting minibuffer-completing-file-name? Is it kosher? Do any of the MH-E developers know why we do this? I'm not sure if the MH-E code is broken and was living on borrowed time or whether a recent change broke Emacs. Please advise. (defun mh-folder-completing-read (prompt default allow-root-folder-flag) Read folder name with PROMPT and default result DEFAULT. If ALLOW-ROOT-FOLDER-FLAG is non-nil then \+\ is allowed to be a folder name corresponding to `mh-user-path'. (mh-normalize-folder-name (let ((minibuffer-completing-file-name t) (completion-root-regexp ^[+/]) (minibuffer-local-completion-map mh-folder-completion-map) (mh-allow-root-folder-flag allow-root-folder-flag)) (completing-read prompt 'mh-folder-completion-function nil nil nil 'mh-folder-hist default)) t)) -- 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: SPC no longer completes when minibuffer-completing-file-name is t
Satyaki Das [EMAIL PROTECTED] wrote: On 12/7/05, Bill Wohler [EMAIL PROTECTED] wrote: In the code below, if I comment out the setting of minibuffer-completing-file-name, the space again performs completion and I can't discern any difference in the completion. What is the effect of setting minibuffer-completing-file-name? Is it kosher? Do any of the MH-E developers know why we do this? I remember adding the binding of minibuffer-completing-file-name because it was needed for proper highlighting of the next character to enter in CVS Emacs. If that isn't needed anymore we can remove it. I'm glad you remembered! Now that you mention it, that variable does have an effect on the highlighting. If it's there the highlighting is correct (I can still complete with TAB, just not with SPC); if it isn't, the highlighting is one character to the right of where it should be. -- 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: custom-set-variables fails to set variable
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote: AFAIK, Gerd isn't listening, so I CC'ed him. Gerd, can you please help? revision 1.2 date: 2003/07/23 00:00:13; author: gm; state: Exp; lines: +5 -1 I don't recognize the author gm, but I'm pretty sure it's not me :-). Ooops ;-). -- 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: custom-set-variables fails to set variable
Stefan Monnier [EMAIL PROTECTED] wrote: revision 1.2 date: 2003/07/23 00:00:13; author: gm; state: Exp; lines: +5 -1 branches: 1.2.2; (define-derived-mode): Mention hook in doc string. Defvar the derived hook. Maybe someone familiar with that code can take it out... I'll gladly take it out if nobody objects. Thanks. I tried taking it out and found that the output of make bootstrap didn't change in a meaningful way. It also fixed the setting of those two MH-E hooks. I'd feel better if someone else who could articulate the reason in the ChangeLog better checked this in. -- 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
apropos-regexp variable void
Input: M-x apropos RET ^run-hooks Output apropos-score-symbol: Symbol's value as variable is void: apropos-regexp In GNU Emacs 22.0.50.2 (i686-pc-linux-gnu, GTK+ Version 2.6.10) of 2005-11-10 on olgas X server distributor `The X.Org Foundation', version 11.0.60802000 configured using `configure '--with-gtk' 'CFLAGS=-g'' Important settings: value of $LC_ALL: en_US 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 locale-coding-system: iso-latin-1 default-enable-multibyte-characters: t Major mode: Fundamental Minor modes in effect: display-time-mode: t desktop-save-mode: t tooltip-mode: t auto-compression-mode: t mouse-wheel-mode: t menu-bar-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: r return r u n - h o o k s return M-x M-p return r u n SPC h o o k s return M-x a p r return ^ r u n - h o o k return C-x 4 b * M e s tab return C-SPC M-b C-p C-f C-f C-f C-f C-f C-f C-f C-f C-f C-f C-f C-f C-f C-f C-f C-f C-f C-a C-SPC C-e M-w M-x e m a c s - b u g return DEL DEL DEL DEL DEL DEL DEL DEL DEL r e p o r tab return Recent messages: Scanning +drafts...done Threading +drafts...done Fontifying show-+drafts... (regexps..) Fontifying show-+drafts... (regexps..) Mark set [2 times] Loading apropos...done Loading help-mode...done apropos-score-symbol: Symbol's value as variable is void: apropos-regexp Mark set [2 times] Loading emacsbug...done -- 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
custom-set-variables fails to set variable
I've found a problem where my mh-letter-mode-hook (in MH-E) isn't getting called. It is listed properly in the custom-set-variables stanza, but when I start Emacs, load MH-E, and run customize-option on mh-letter-mode-hook, the hook is empty! When I enter the hook function, the hook works again. Is it because MH-E isn't loaded when custom-set-variables is run? Is it something MH-E is doing when it is loaded? I do not see this behavior under Emacs 21 so this is a regression. I intend to go through the rest of my customization variables to see if this a trend or an isolated problem. I'll follow up on this thread when I do. In GNU Emacs 22.0.50.2 (i686-pc-linux-gnu, GTK+ Version 2.6.10) of 2005-11-10 on olgas X server distributor `The X.Org Foundation', version 11.0.60802000 configured using `configure '--with-gtk' 'CFLAGS=-g'' Important settings: value of $LC_ALL: en_US 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 locale-coding-system: iso-latin-1 default-enable-multibyte-characters: t Major mode: MH-Folder Minor modes in effect: hl-line-mode: t display-time-mode: t desktop-save-mode: t tooltip-mode: t auto-compression-mode: t mouse-wheel-mode: t menu-bar-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 transient-mark-mode: t Recent input: h v a DEL DEL a v i o r SPC s o SPC DEL DEL DEL o r SPC s h o u l d SPC I SPC r e p o r t SPC i t SPC C-SPC C-p C-f C-f C-f C-f C-f C-f C-f C-f C-f C-w C-a C-n C-SPC C-p C-p C-p C-p C-p C-p C-p C-p C-p C-n C-w C-c C-c SPC SPC SPC SPC SPC i return C-n C-n C-n C-n C-n C-n C-n C-n C-p C-x 4 b d r tab M-x r e p o r t - e m return Recent messages: Auto-saving...done Mark set [2 times] Spell checking region using aspell with default dictionary... Spell-checking using aspell with default dictionary done Wrote /home/wohler/var/mail/drafts/5 Sending...backgrounded inc +inbox...done Fontifying show-+inbox... (regexps..) Quit Loading emacsbug...done -- 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: custom-set-variables fails to set variable
Bill Wohler [EMAIL PROTECTED] writes: I've found a problem where my mh-letter-mode-hook (in MH-E) isn't getting called. It is listed properly in the custom-set-variables stanza, but when I start Emacs, load MH-E, and run customize-option on mh-letter-mode-hook, the hook is empty! When I enter the hook function, the hook works again. Is it because MH-E isn't loaded when custom-set-variables is run? Is it something MH-E is doing when it is loaded? I do not see this behavior under Emacs 21 so this is a regression. It is not documented in NEWS, either. I intend to go through the rest of my customization variables to see if this a trend or an isolated problem. I'll follow up on this thread when I do. Boy howdy! It is a trend. When I bring up a customization buffer for each of my customization variables, some look good (are set correctly, have a state of saved, and have documentation). However, the rest have a value of nil or are just empty (mostly hooks), have a state of changed, and do not have documentation strings. The ones that are OK are either in files that are in preloaded-file-list or have ;;;###autoload cookies. There are two solutions 1. Preserve the Emacs 21 semantics which had the effect of remembering customization settings in customize-set-variables so that when the modules were eventually loaded, the user's settings took precendence. 2. Add lots of lots of ;;;###autoload cookies to defcustoms everywhere. I am but one small user, but my list of broken customization variables is long (appended below). I suspect that option #2 is the preferred approach as it has the advantage of providing docstrings and customizationability to options in unloaded packages. It looks like the great majority of these are in the Gnus and MH-E packages. If a Gnus person can handle the Gnus options, I can handle the MH-E options, and Peter can handle the Debian options. Richard, should someone take the responsibility of ensuring that all of the defcustom options are autoloaded? Do *all* of the options need to be autoloaded? Or just the right ones (whatever that is)? - List of broken options in ~wohler/.emacs.custom - Man-notify-method c-backslash-column canlock-password cperl-font-lock cperl-indent-level cperl-lazy-help-time cperl-under-as-char cvs-confirm-removals debian-bug-always-CC-myself debian-bug-menu-action-default debian-bug-menu-preload-flag gnus-agent-expire-days gnus-asynchronous gnus-before-startup-hook gnus-default-article-saver gnus-directory gnus-group-line-format gnus-interactive-catchup gnus-interactive-exit gnus-large-newsgroup gnus-message-archive-group gnus-message-archive-method gnus-orphan-score gnus-read-active-file gnus-read-newsrc-file gnus-save-killed-list gnus-save-newsrc-file gnus-score-expiry-days gnus-secondary-select-methods gnus-summary-line-format gnus-summary-mode-hook gnus-thread-expunge-below gnus-thread-hide-subtree gnus-thread-sort-functions gnus-updated-mode-lines gnus-visible-headers gpg-passphrase-timeout ispell-program-name jde-db-source-directories jde-project-file-name jde-use-font-lock log-edit-hook lpr-page-header-program lpr-page-header-switches mail-source-delete-incoming mail-sources message-auto-save-directory message-directory message-mail-user-agent message-send-hook message-sent-hook message-user-organization mh-alias-insertion-location mh-auto-fields-list mh-before-quit-hook mh-before-send-letter-hook mh-compose-skipped-header-fields mh-compose-space-does-completion-flag mh-default-folder-must-exist-flag mh-default-folder-prefix mh-delete-yanked-msg-window-flag mh-display-buttons-for-alternatives-flag mh-do-not-confirm-flag mh-folder-mode-hook mh-identity-default mh-identity-list mh-inc-folder-hook mh-index-new-messages-folders mh-index-ticked-messages-folders mh-invisible-header-fields mh-invisible-header-fields-default mh-junk-background mh-junk-disposition mh-large-folder mh-letter-mode-hook mh-lpr-command-format mh-mime-save-parts-default-directory mh-quit-hook mh-recenter-summary-flag mh-recursive-folders-flag mh-reply-default-reply-to mh-show-mode-hook mh-show-threads-flag mh-show-use-goto-addr-flag mh-tool-bar-folder-buttons mh-yank-behavior mm-discouraged-alternatives mm-inline-large-images mm-inline-text-html-with-images mm-text-html-renderer nnmail-keep-last-article nnmail-prepare-incoming-hook pgg-encrypt-for-me pgg-query-keyserver smiley-data-directory speedbar-hide-button-brackets-flag speedbar-use-images w3m-content-type-alist w3m-key-binding w3m-use-favicon -- Bill Wohler [EMAIL PROTECTED] http://www.newt.com
Re: apropos-regexp variable void
Romain Francoise [EMAIL PROTECTED] writes: Bill Wohler [EMAIL PROTECTED] writes: apropos-score-symbol: Symbol's value as variable is void: apropos-regexp This use had escaped the renaming to `apropos-pattern', I fixed it. Thanks. Confirmed fixed, thanks! p.s. Saw the following when compiling: In end of data: apropos.el:963:1:Warning: the function `help-buffer' is not known to be defined. -- 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: custom-set-variables fails to set variable
Luc Teirlinck [EMAIL PROTECTED] writes: custom-set-variables defvar defcustom: The defvar wins. Thanks very much for the explanation. Too bad I didn't read this before sending my last note. I evidently got confused when I ran my last test. After loading MH-E, I found that the list I previously posted was reduced to the following: mh-inc-folder-hook mh-letter-mode-hook mh-show-mode-hook I'm still a bit confused though. For example, mh-show-mode-hook is defined implicitly by the definition of mh-show-mode in mh-utils.el which requires mh-customize.el which contains the defcustom of mh-show-mode-hook. Shouldn't that defcustom have won against the defvar in the mh-show-mode? I'd still be curious to hear the opinions on whether one should use the ;;;###autoload cookie on the defcustoms or not. Also, why does the same code work in Emacs 21 and not in Emacs 22? -- 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: custom-set-variables fails to set variable
Luc Teirlinck [EMAIL PROTECTED] wrote: Bill Wohler wrote: Also, why does the same code work in Emacs 21 and not in Emacs 22? I believe that I answered this in an earlier reply, but maybe you had not yet read that reply when you asked this. Yes, that is correct. I liked your proposal to revert to Emacs 21 semantics. This would also fix the problem with the two broken MH-E hooks which, as far as I can tell, shouldn't be broken (although I might be confused about how require works ;-). (Who knows how many other hooks are broken in the same way.) If Gerd is listening, perhaps he can let us know why he added that defvar: revision 1.2 date: 2003/07/23 00:00:13; author: gm; state: Exp; lines: +5 -1 branches: 1.2.2; (define-derived-mode): Mention hook in doc string. Defvar the derived hook. Maybe someone familiar with that code can take it out... -- 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: apropos-regexp variable void
Stefan Monnier [EMAIL PROTECTED] wrote: p.s. Saw the following when compiling: In end of data: apropos.el:963:1:Warning: the function `help-buffer' is not known to be defined. It's harmless. Harmless or not, we don't allow any compiler errors in MH-E so that any real error stands out like a sore thumb rather than being hidden in a forest. I'd encourage this convention for the Emacs project as a whole. -- 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: Menu bar font awry
Luc Teirlinck [EMAIL PROTECTED] wrote: Bill Wohler wrote: With today's CVS, the font in the menu bar got really small and the background went white. Is anyone else seeing this? Not me. Thanks, Luc. I just discovered my error: I forgot to add --with-gtk last time I ran ./configure. -- 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
Menu bar font awry
With today's CVS, the font in the menu bar got really small and the background went white. Is anyone else seeing this? -- 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: font-lock is broken
Stefan Monnier [EMAIL PROTECTED] writes: Make a buffer with this content: In-reply-to: foo bar of Fri, 15 Jul 2005 20:31:33 EDT (2 lines only) Then M-x mh-letter-mode M-x font-lock-fontify-buffer You get: font-lock-default-fontify-region: Wrong type argument: number-or-marker-p, nil This is introduced by my recent change to font-lock.el which checks that we do not get stuck in an empty match. Problem is that it bumps into a minor bug in mh-font-lock-field-data: (defun mh-font-lock-field-data (limit) ... (if (and field (mh-letter-skipped-header-field-p field)) (set-match-data nil) (set-match-data (list data-begin data-end data-begin data-end))) (goto-char (if (equal point data-end) (1+ data-end) data-end)) t))) As you can see, this function sometimes returns non-nil (i.e. it says it's found a match) but with no begin/end of match 0. Thanks for pointing this out. That should make it easy for us to fix. -- 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: font-lock is broken
Bill Wohler [EMAIL PROTECTED] writes: Stefan Monnier [EMAIL PROTECTED] writes: Make a buffer with this content: In-reply-to: foo bar of Fri, 15 Jul 2005 20:31:33 EDT (2 lines only) Then M-x mh-letter-mode M-x font-lock-fontify-buffer You get: font-lock-default-fontify-region: Wrong type argument: number-or-marker-p, nil This is introduced by my recent change to font-lock.el which checks that we do not get stuck in an empty match. Problem is that it bumps into a minor bug in mh-font-lock-field-data: (defun mh-font-lock-field-data (limit) ... (if (and field (mh-letter-skipped-header-field-p field)) (set-match-data nil) (set-match-data (list data-begin data-end data-begin data-end))) (goto-char (if (equal point data-end) (1+ data-end) data-end)) t))) As you can see, this function sometimes returns non-nil (i.e. it says it's found a match) but with no begin/end of match 0. Thanks for pointing this out. That should make it easy for us to fix. Thanks to Satyaki Das, this has been fixed in the MH-E repository. It will appear in the Emacs repository in the next week or so when I transition the MH-E project to use the Emacs repository as its master. -- 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: Some mistakes in recent CVS code
Richard Stallman [EMAIL PROTECTED] wrote: I'll fix the warnings in the MH-E package unless you've already done so. Thanks. I just checked MH-E version 7.84 into CVS Emacs. All of the files in the package compile without warning. -- 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: Some mistakes in recent CVS code
Richard Stallman [EMAIL PROTECTED] writes: I will fix most of the rest now. I'll fix the warnings in the MH-E package unless you've already done so. -- 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
