From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: [drew.adams@oracle.com: RE: weirddefadvicebugwithbyte-compilation] Date: Tue, 13 Dec 2005 17:05:02 -0800 Message-ID: References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1134522417 9420 80.91.229.2 (14 Dec 2005 01:06:57 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 14 Dec 2005 01:06:57 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Dec 14 02:06:53 2005 Return-path: Original-Received: from [199.232.75.2] (helo=lists.gnu.org) by ciao.gmane.org with esmtp (Exim 4.43) id 1EmL5X-00055C-Ka for ged-emacs-devel@m.gmane.org; Wed, 14 Dec 2005 02:05:48 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EmL66-0008DS-90 for ged-emacs-devel@m.gmane.org; Tue, 13 Dec 2005 20:06:22 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EmL5X-0008Aa-Mz for emacs-devel@gnu.org; Tue, 13 Dec 2005 20:05:48 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EmL5U-00088k-VP for emacs-devel@gnu.org; Tue, 13 Dec 2005 20:05:46 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EmL5U-00087n-Ff for emacs-devel@gnu.org; Tue, 13 Dec 2005 20:05:44 -0500 Original-Received: from [148.87.122.30] (helo=rgminet01.oracle.com) by monty-python.gnu.org with esmtp (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.34) id 1EmL7T-0004uO-Fa for emacs-devel@gnu.org; Tue, 13 Dec 2005 20:07:47 -0500 Original-Received: from rgmsgw300.us.oracle.com (rgmsgw300.us.oracle.com [138.1.186.49]) by rgminet01.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id jBE156FU018901 for ; Tue, 13 Dec 2005 18:05:06 -0700 Original-Received: from rgmsgw300.us.oracle.com (localhost [127.0.0.1]) by rgmsgw300.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jBE155tm017191 for ; Tue, 13 Dec 2005 18:05:05 -0700 Original-Received: from dradamslap (dhcp-amer-rmdc-csvpn-gw5-141-144-106-118.vpn.oracle.com [141.144.106.118]) by rgmsgw300.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with SMTP id jBE153ar017158 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 13 Dec 2005 18:05:05 -0700 Original-To: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org X-Broken-Reverse-DNS: no host name found for IP address 199.232.75.2 Xref: news.gmane.org gmane.emacs.devel:47662 Archived-At: Not sure what you want. Below is the test case again. It is self-contained for reproducing the crash bug (on Windows). Are you perhaps asking about the define-minor-mode questions, or is this what you wanted? That is the test case I tested before. Are you perhaps asking about the define-minor-mode questions, Yes--here's what I said: Please see my previous emails, where I describe the original case (which uses define-minor-mode). Could you send that test case again? My response refers to "the original case". I shouldn't have said "original case", but "original context". That is what led to the misunderstanding. What you tested was the original case I submitted. It contains everything needed for the crash bug. What I was referring to was my original use context. You don't want all the files I load (but I can point you to them, if you like). I described what I did, but I will try to be clearer here. Let me know if this is what you want or not. 1. I load files of mine with stuff like that shown in bar.el - just think of this code as being in my .emacs. 2. I load a file of mine that does a defadvice like that seen in bar.el. It has the `compile' keyword. There is no mention of variable `my-mode' or foo.el in that file. To me, that defadvice should have no connection with the problems seen, but if I don't do that defadvice the problem goes away. 3. I do (require 'foo) from a file I load (e.g. .emacs). foo.el has (provide 'foo). 4. In foo.el, I do, _in order_: a. A defvar of a keymap variable, followed by code that defines keys in that map and does (put ... 'menu-enable (and my-mode...)). This includes menu-bar bindings for the (existing) Search menu. b. A defadvice like the one shown in foo.el. It has _no_ `compile'. The body refers to variable `my-mode'. c. A define-minor-mode for mode `my-mode'. d. This, at the very end (of foo.el): (if my-mode (my-mode 1)). I do that to make sure that the mode-line lighter correctly corresponds to the mode state (on/off). 5. Near the end of my .emacs (after loading foo.elc), I do this: (my-mode 1). Here's my understanding of the "problems" (or misunderstanding on my part) surrounding `define-minor-mode': 1. When foo.elc is loaded, it adds a binding to the menu-bar Search map, and it adds a corresponding `menu-enable' that tests `my-mode'. 2. Then, loading foo.elc causes the defadvice in that file to be byte-compiled. I do not understand why, since there is no `compile' in it. 3. That byte-compilation causes a warning to be displayed in buffer *Compile Log*. 4. To display *Compile Log*, a new frame is created, because of the special-display regexp. 5. When creating the new frame, the menu-bar Search menu is created for it, and the `menu-enable' property with test `my-mode' is evaluated. 6. Since the `define-minor-mode' has not yet been evaluated during loading of foo.elc, `my-mode' is still unbound when it is evaled for the Search menu, so a backtrace is displayed with a void-variable error. 7. The backtrace is also a special-display buffer, so a new frame is created to display it, provoking the same problem of step 5. Eli has explained the ensuing crash bug on Windows. If I don't use `define-minor-mode', I will naturally place a defcustom for `my-mode' near the beginning of file foo.el. I was mistakenly expecting that the automatic generation of the defcustom by `define-minor-mode' would also, in effect, place it near the beginning of the byte-compiled file foo.elc. Naive. Now I understand that I must either place the `define-minor-mode' at the file beginning or use an explicit defcustom (can I use a defcustom plus `define-minor-mode' here, or will that provoke an error?). Actually, it is sufficient to place the `define-minor-mode' before the defadvice in foo.el. I still don't understand why the defadvice in foo.el, which has no `compile', is byte-compiled on the fly. Nor do I understand why removing the defadvice from bar.el (which has a `compile') causes the error to go away. It's as if the `compile' from bar.el's defadvice were somehow transferred to foo.el's defadvice, or the `compile' turned on a compile-advices-from-now-on mode, so foo.el's defadvice was also compiled. I'm unclear on the way to use defadvice, I guess. I'm not claiming there is actually anything wrong (another bug). I'm just confessing my confusion and naive expectations for `define-minor-mode'. IIUC, we tell people to use the minor-mode function to set the minor-mode variable, so that's what I do in .emacs. If I instead set the variable there (setq), there is of course no unbound-variable error. If there is a lesson here, besides my own learning, perhaps it is that we could explain the use of `define-minor-mode' a bit better. And I wonder about the behavior of the on-the-fly defadvice byte-compiling. Again, I'm no doubt confused about that - I'd like to understand what's happening there and why. Does this help? If not, I'll be glad to point you to the source files. They're all on Emacs Wiki.