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 19:02:34 -0500 Message-ID: <007701c9e63a$18b24e00$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> <000601c9e5b5$fd363800$650aa8c0@austin.rr.com> <4A28E4AC.1000506@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 1244246217 7571 80.91.229.12 (5 Jun 2009 23:56:57 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 5 Jun 2009 23:56:57 +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 Sat Jun 06 01:56: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 1MCjHK-0007bb-J9 for geh-help-gnu-emacs@m.gmane.org; Sat, 06 Jun 2009 01:56:54 +0200 Original-Received: from localhost ([127.0.0.1]:33250 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MCjHJ-00032Y-Lm for geh-help-gnu-emacs@m.gmane.org; Fri, 05 Jun 2009 19:56:53 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MCjGw-00031h-Sd for help-gnu-emacs@gnu.org; Fri, 05 Jun 2009 19:56:30 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MCjGs-00030b-1V for help-gnu-emacs@gnu.org; Fri, 05 Jun 2009 19:56:30 -0400 Original-Received: from [199.232.76.173] (port=41601 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MCjGr-00030Y-Ta for help-gnu-emacs@gnu.org; Fri, 05 Jun 2009 19:56:25 -0400 Original-Received: from hrndva-omtalb.mail.rr.com ([71.74.56.125]:58654) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MCjGr-0002OO-HX for help-gnu-emacs@gnu.org; Fri, 05 Jun 2009 19:56:25 -0400 Original-Received: from unknown0 ([66.68.143.33]) by hrndva-omta03.mail.rr.com with SMTP id <20090605235624268.XHGR6499@hrndva-omta03.mail.rr.com>; Fri, 5 Jun 2009 23:56:24 +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-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:64984 Archived-At: Martin: > 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. Interesting. I had not known that this was a known and knotty issue - just that it was an annoyance to me. I will happily adopt the backslash way, as I do see that it is better. (I just never thought of it. If there is documentation on this subject, I never ran across it.) Martin, regarding filladapt: > 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. OK. filladapt is out! ;-) I wonder why the Debian folks thought it a worthwhile addition ("emacs goodies"). > > 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. There is probably something I do not understand. I don't think the variables in question are mine to defvar. They belong to packages I might use but do not load by default. I think this is a problem that the customization stuff is supposed to address; but a lot of this got into my code before customization was implemented. I recognize the variables in the warnings and know that it is not a problem. In a file which is entirely my own code and not trying to set up variables for some other package, I do take care of all such warnings. Even in my initialization, the code that makes the reference is often guarded so that it will not execute if the symbol is not defined; but the compiler worries about the reference anyway. > > 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? ? The context above is for emacs -Q. The two 'customizations' mentioned are literal and the only ones that happened. I think there is a difference between setq and custom-set-variables that is critical here. > > 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'? "\f\\|[ ]*$" and "[ \f]*$ after emacs -Q and they did not change after I did the 1-variable custom-set-variables. (The second character after each `[' is supposed to be a tab; but that may get fouled up in the mail.) I also checked them when *Compile Log* was the current buffer. > 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 :-( Are we giving up? This dialogue has been informative for me - even if we did not solve the problem. I learned about other things I needed to know, and you were patient to teach me. Thank you. I find it strange that you could not reproduce the symptom, since I can produce it with emacs -Q and a single customization. Furthermore, I can also produce it with the Windows implementation running under Vista (also v23). Fortunately my workaround is effective. Regards, David V.