From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "David Vanderschel" Newsgroups: gmane.emacs.help Subject: Re: byte-compile making erroneous *Compile Log* Date: Fri, 5 Jun 2009 03:16:54 -0500 Message-ID: <000601c9e5b5$fd363800$650aa8c0@austin.rr.com> References: loom.20090602T003509-287@post.gmane.org <4A24C568.6090609@gmx.at> <000401c9e4da$2e106680$650aa8c0@austin.rr.com> <4A2773E2.9030001@gmx.at> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1244209586 27381 80.91.229.12 (5 Jun 2009 13:46:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 5 Jun 2009 13:46:26 +0000 (UTC) Cc: help-gnu-emacs@gnu.org To: "martin rudalics" Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Fri Jun 05 15:46:23 2009 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1MCZkU-00037l-Ux for geh-help-gnu-emacs@m.gmane.org; Fri, 05 Jun 2009 15:46:23 +0200 Original-Received: from localhost ([127.0.0.1]:58865 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MCZkU-0000Di-4m for geh-help-gnu-emacs@m.gmane.org; Fri, 05 Jun 2009 09:46:22 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MCUVv-00015g-3Q for help-gnu-emacs@gnu.org; Fri, 05 Jun 2009 04:10:59 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MCUVq-00010z-Ci for help-gnu-emacs@gnu.org; Fri, 05 Jun 2009 04:10:58 -0400 Original-Received: from [199.232.76.173] (port=39862 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MCUVq-00010m-3x for help-gnu-emacs@gnu.org; Fri, 05 Jun 2009 04:10:54 -0400 Original-Received: from hrndva-omtalb.mail.rr.com ([71.74.56.123]:48518) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MCUVp-00024T-7Q for help-gnu-emacs@gnu.org; Fri, 05 Jun 2009 04:10:54 -0400 Original-Received: from unknown0 ([66.68.143.33]) by hrndva-omta02.mail.rr.com with SMTP id <20090605081045237.YTGM23263@hrndva-omta02.mail.rr.com>; Fri, 5 Jun 2009 08:10:45 +0000 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-detected-operating-system: by monty-python.gnu.org: Solaris 10 (1203?) X-Mailman-Approved-At: Fri, 05 Jun 2009 09:41:21 -0400 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:64966 Archived-At: David, regarding edebug-eval-defun on fill-region from filladapt.el: >> It fails. So does eval-defun. The problem is >> that, in the documentation string for the >> function, there is a `(' in the first column. >> I've run into this before. The function will >> compile properly, but evaling the defun >> interactively is problematic and the symptoms can >> get very weird. Because of this, I long ago took >> to formatting documentation strings with a space >> in column 1, for otherwise filling could >> inadvertently result in a `(' in col. 0. Martin: > I usually put a backslash in front of any parentheses within > doc-strings so they won't interfere with filling. I want them to be subject to fill. I just don't want them winding up in col. 0, so I have a 1-blank fill-prefix throughout all my doc strings that might contain parens. The symptoms resulting from a `(' in col. 0 are serious and bizarre. The reported error depends on where in the defun point lies when you request the eval. Strangely, if you go to the end of the defun and do eval-last-sexp, it works. This problem has existed for years. >> I discovered that the instance of fill-region that >> find-function found is actually an old one in >> filladapt.el in my private lisp directory. (Goes >> back to 2002. Not sure why I had my own copy.) >> So I figured that was the problem. After I fixed >> it so that find-function was finding the right one >> in the emacs lisp directory, I was dismayed to >> discover that it _still_ does not work. Indeed the >> `(' in col. 0 still exists and still causes >> problems. But the wrong behaviour in >> *Compile Log* continues; so it was not the fault >> of my old private copy. (Yes, I also hid the .elc.) > But you probably didn't evaluate the version in the lisp directory so > you were still using the one with the bad doc-string. No. I reloaded Emacs after I removed filladapt from my local directory. The _latest_ version (i.e., distributed with v23 emacs-snapshot) still has a `(' in col. 0. As I said, it will compile OK that way. When I did find-function, I could see in which directory lay the file: filladapt.el -> /usr/share/emacs/site-lisp/emacs-goodies-el/filladapt.el This is from emacs-snapshot - v23.0.91.1 - straight from Debian. The following are the first few lines of the defun: ______________________________________________________________________ (defun fill-region (beg end &optional justify nosqueeze to-eop) "Fill each of the paragraphs in the region. (This function has been overloaded with the `filladapt' version.) Prefix arg (non-nil third arg, if called from program) means justify as well. ______________________________________________________________________ You can see the troublesome open paren in there. >Don't care about byte-compiling when doing these >things. Use `eval-buffer' instead, it will also give >you less headaches while debugging. Indeed. I also use eval-defun and eval-region depending on what I have fooled with. >> (If you ask to what key is bound eval-defun, it >> says \C-\M-x and \M-X, but those are really >> bindings for edebug-eval-defun.) > C-M-x is aliased to `edebug-eval-defun' which calls `eval-defun' when > there's no prefix argument. What is "\M-X"? shift meta x. I see now that it is a private binding I made because \C-\M-x conflicted with a global keybinding I had done in Windows (and eventually abandoned in favor of global bindings based on the Windows key, since I steered clear of the Super- modifier in Emacs). I have now adapted my initialization for Ubuntu; and that key binding is not harmful. I was confused because in Emacs v20, there really was a separate function edebug-eval-defun provided by edebug itself. (However, it also overrode eval-defun so that the prefix trick did work there also.) >> The reason that some "In : " >> strings do not get merged with the following line is >> that fill-region is _not_ called in those cases. >> Looking at the code for display-warning, it appears >> that fill-region is called only when >> warning-fill-prefix is not nil (its default). But I >> did not see any code that could change it, so I don't >> know what causes that - especially dynamically during >> the compilation. > Mabye there is a "\n" in MESSAGE already and the > code is skipped? Now I have run the debugger in display-warning. And a \n is the reason for skipping those that are skipped and which come out OK. Some of the warnings do have \n's in them. (I guess display-warning figures that, if the message already contains \n's, then it must have already been formatted with correct filling and that it needs no filling.) The most common sort of warning that is causing the symptom is assignment to a free variable. (Some of those are unavoidable as far as I can tell.) It strikes me that it is basically wrong for display-warning to include the "In : " line in the region it passes to fill-region. Furthermore, I don't see how it is happening because display-warning sets its start variable (for the beginning of the region to fill) to (point) before inserting the message. >> ... It turns out that >> paragraph-ignore-fill-prefix was the cause after all. >> I don't know what went wrong with my test when I >> thought I had changed it to nil. But when it is t, >> the compile log gets fouled up. I can live with nil. >> >> Thanks, Martin, for the pointers. Do I need to report >> the bug, or are you pursuing it? > I don't know because I can't reproduce it yet. Can > you reproduce it with emacs -Q and > `paragraph-ignore-fill-prefix' set to t? Yes. But there is something strange here. If I do emacs -Q and (setq paragraph-ignore-fill-prefix t), it still works correctly. But if I do (custom-set-variables '(paragraph-ignore-fill-prefix t)), then it screws up. I did not know that custom-set-variables could have side effects. >I suppose your old filladapt code still gets called >somewhere in between. You should try to get rid of >it somehow, at least for testing this. No way. I think I confused you by even mentioning that I had had an old version. I really did fix that. (I also realize now that the reason I had a copy in my private lisp directory is that filladapt is not part of the regular Emacs package.) Now it turns out that there is an issue about which fill-region gets called. With emacs -Q there is no (require 'filladapt), so the fill-region is that from fill.el. However, the behaviours (right and wrong) occur the same with either fill-region. > In any case the `fill-region' call in `display-warning' should handle > any prefix specified by `warning-fill-prefix' so this should not be ever > ignored via `paragraph-ignore-fill-prefix'. Just that I don't see any > code where `paragraph-ignore-fill-prefix' might affect the behavior of > `fill-region'. I would like to think that fill-region is doing nothing wrong. OTOH, I have now verified that, with emacs -Q, fill-region is still being called on the messages with no \n; and, when there is a "In :" line preceding, it is included in the region and it does not get fouled up. Speculation: Under the right circumstances the colon in the defun ID line somehow makes that a paragraph end. I'll be interested to see if you can reproduce it now. I remain willing to pursue other lines of inquiry if you cannot. The problem also exists in Emacs v22. Regards, David V.