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: Sat, 06 Jun 2009 10:21:22 +0200 Message-ID: <4A2A2702.6070707@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> <4A28E4AC.1000506@gmx.at> <007701c9e63a$18b24e00$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 1244276515 27217 80.91.229.12 (6 Jun 2009 08:21:55 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 6 Jun 2009 08:21:55 +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 Sat Jun 06 10:21:51 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 1MCr9x-0000qV-U2 for geh-help-gnu-emacs@m.gmane.org; Sat, 06 Jun 2009 10:21:50 +0200 Original-Received: from localhost ([127.0.0.1]:36228 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MCr9w-0003AG-VR for geh-help-gnu-emacs@m.gmane.org; Sat, 06 Jun 2009 04:21:48 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MCr9d-0003A9-DX for help-gnu-emacs@gnu.org; Sat, 06 Jun 2009 04:21:29 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MCr9a-00039F-3b for help-gnu-emacs@gnu.org; Sat, 06 Jun 2009 04:21:29 -0400 Original-Received: from [199.232.76.173] (port=32985 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MCr9Z-00039C-Rf for help-gnu-emacs@gnu.org; Sat, 06 Jun 2009 04:21:25 -0400 Original-Received: from mail.gmx.net ([213.165.64.20]:57175) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1MCr9Z-0006QT-Ad for help-gnu-emacs@gnu.org; Sat, 06 Jun 2009 04:21:25 -0400 Original-Received: (qmail invoked by alias); 06 Jun 2009 08:21:23 -0000 Original-Received: from 62-47-63-116.adsl.highway.telekom.at (EHLO [62.47.63.116]) [62.47.63.116] by mail.gmx.net (mp035) with SMTP; 06 Jun 2009 10:21:23 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1/uD3Iy/vDulxojHvjZNs4pRg4/enGp3OhmHgqA69 RdxO4SfOyzO6VW User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) In-Reply-To: <007701c9e63a$18b24e00$650aa8c0@austin.rr.com> X-Y-GMX-Trusted: 0 X-FuHaFi: 0.57 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:64987 Archived-At: > 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.) You should read section 30.2.1 of the Emacs manual entitled "Left Margin Convention" and also follow the references cited there. > 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. When you _know_ that `foo' is defined elswhere you tell the byte-compiler to not worry about it by putting a (defvar foo) in your file. Thus the compiler will only flag the cases where you either have forgotten to pacify it or where you really should have defined and initialized the variable writing something like (defvar foo nil) For functions use `declare-function' to pacify the byte-compiler. >> 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? Certainly not. But since this is bug is already in Emacs 22 there's no need to find a quick fix for Emacs 23.1 anyway. It should get fixed for the 23.2 release though. > 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. Because I didn't care ;-) For anyone interested, the following simple scenario using Emacs -Q should exhibit the bug: STEP1: Via the customization interface (`customize-option') set the variable `paragraph-ignore-fill-prefix' to `t'. STEP2: Byte-compile an Elisp file foo.el containing the five lines (defun foo (a) a) (defun bar (a) (foo a a)) This should get you a *Compile-Log* buffer witht the line In bar: foo.el:5:4:Warning: foo called with 2 arguments, but accepts only 1 STEP3: In the *Compile-Log* buffer hit RET with point somewhere on In bar: foo.el This should prompt you like Find this error in (default In bar: foo.el): which is misleading and silly. Moreover, unless you now manually type in the name of the source file, Emacs won't be able to find it. martin