From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.help Subject: Re: byte-compile making erroneous *Compile Log* Date: Fri, 05 Jun 2009 11:26:04 +0200 Message-ID: <4A28E4AC.1000506@gmx.at> References: loom.20090602T003509-287@post.gmane.org <4A24C568.6090609@gmx.at> <000401c9e4da$2e106680$650aa8c0@austin.rr.com> <4A2773E2.9030001@gmx.at> <000601c9e5b5$fd363800$650aa8c0@austin.rr.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1244194019 9592 80.91.229.12 (5 Jun 2009 09:26:59 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 5 Jun 2009 09:26:59 +0000 (UTC) Cc: help-gnu-emacs@gnu.org To: David Vanderschel Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Fri Jun 05 11:26:55 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 1MCVhN-0001Xv-A5 for geh-help-gnu-emacs@m.gmane.org; Fri, 05 Jun 2009 11:26:53 +0200 Original-Received: from localhost ([127.0.0.1]:34269 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MCVhM-0007dc-5F for geh-help-gnu-emacs@m.gmane.org; Fri, 05 Jun 2009 05:26:52 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MCVgl-0007dX-Oo for help-gnu-emacs@gnu.org; Fri, 05 Jun 2009 05:26:15 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MCVgg-0007dL-Nj for help-gnu-emacs@gnu.org; Fri, 05 Jun 2009 05:26:14 -0400 Original-Received: from [199.232.76.173] (port=52308 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MCVgg-0007dI-I1 for help-gnu-emacs@gnu.org; Fri, 05 Jun 2009 05:26:10 -0400 Original-Received: from mail.gmx.net ([213.165.64.20]:35850) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1MCVgf-0000Pl-TD for help-gnu-emacs@gnu.org; Fri, 05 Jun 2009 05:26:10 -0400 Original-Received: (qmail invoked by alias); 05 Jun 2009 09:26:06 -0000 Original-Received: from 62-47-61-54.adsl.highway.telekom.at (EHLO [62.47.61.54]) [62.47.61.54] by mail.gmx.net (mp017) with SMTP; 05 Jun 2009 11:26:06 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1/TOqla5Z7TxjR7Iu1pFT/WjMkqnohx18Uk+OahnJ VA8cV8i2P4pgXk User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) In-Reply-To: <000601c9e5b5$fd363800$650aa8c0@austin.rr.com> X-Y-GMX-Trusted: 0 X-FuHaFi: 0.65 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) 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:64960 Archived-At: >> 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. Backslashes won't harm the filling ;-) > 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. Obviously so since you are scannning balanced parens backwards here. No need for finding the start of a defun. > This problem has existed for years. Ever since. A paren in column zero signifies the start of a defun regardless of whether it's in a string, a comment, or what have you. In some modes setting `open-paren-in-column-0-is-defun-start' to nil will suppress this semantics but I'd strongly advise against doing that. The c-mode designers tried to do more or less that and came up with slowing down Emacs considerably. For some time Emacs highlights such parens in column zero with a warning face. Anyway, the canonical way for handling left parens in Elisp-strings is to put a backslash in front. > 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. This is old (1998, probably XEmacs ready) style. I don't use it and wouldn't use it with Emacs 22/23 because the interactions are completely unpredictable also because greater parts of the filling code have been rewritten since then. If filladapt has functionality current Emacs doesn't provide it should be added. >> 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.) It's probably afraid of messing up the code (note that `display-warning' has to deal with all sorts of compiler-emitted text). > 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.) No. You should always put the appropriate (defvar foo) in your buffer/file to suppress the warnings. Otherwise you hardly ever find out whether there _is_ an erroneously undefined variable. > 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. Maybe `fill-region' is supposed to fill the "In ..." stuff, for example, when all this is about one warning in one defun. It mustn't mess up the file references though. > 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. Could it be made buffer-local by some package loaded in your .emacs? > 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. I'll take your word for it. > 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. What are your values of `paragraph-start' and `paragraph-separate'? Anyway, I can manually fill the region in that buffer and see that it messes up the file reference in the way you described (1) because `fill-region' doesn't insert a space after the colon, and (2) because the "In ..." text inherits the text properties of the file string. Twice wrong doesn't do any good here :-( martin