byte-compile making erroneous *Compile Log*

byte-compile making erroneous *Compile Log*

[David Vanderschel]

The typical message looks like the following:

    eemacs.el:233:25:Warning: assignment to free variable `w32-lwindow-modifier'

The first part is a link into the file and that works fine.  However, if the
'error' is found in a defun, I get something like the following:

   In dv-java-keys:  eemacs.el:223:9:Warning: assignment to free variable
    `c-basic-offset'

and then the link does not work, because the follower logic believes that the
"In <defun-name>" is part of the file name.

Now this does not happen when I start Emacs with "emacs -Q".  So I am trying
without luck to figure out what in my initialization is causing the extra defun
identifier to appear.  I thought maybe the "verbose" option for the bytecomp
group might be relevant, but no joy there.  Checking other things that I thought
might be relevant, I am failing to find it.  My initialization is a bit too
large to try to narrow it down by partial execution; so I am hoping that someone
has enough insight into this behaviour to point me to something that could be
causing it.

Emacs version: GNU Emacs 22.2.1 (i486-pc-linux-gnu, GTK+ Version 2.14.1) of
2008-09-05 on vernadsky, modified by Ubuntu

Running under Ubuntu 9.04.

RE: byte-compile making erroneous *Compile Log*

[Drew Adams]

> Now this does not happen when I start Emacs with "emacs -Q".  
> So I am trying without luck to figure out what in my
> initialization is causing...

> My initialization is a bit too large to try to narrow it down
> by partial execution...

No, it's not too large. What you need to do (unless someone here has a direct
answer for your problem) is to look for the problem using _binary_ search.

This a very quick way to locate the problem. Remember the story of the King's
agreement to give a bargainer one grain of rice for the first square of a
checkerboard, 2 grains for the second square, 4 grains for the third square, and
so on. Doubling or halving something picks up steam very quickly
(exponentially!).

By commenting out sections of your init file (use `M-x comment-region', which
you might want to bind to a key - I use `C-x C-:') and uncommenting them (just
use `C-u' with `comment-region'), split your init file up, in effect, to find
the problem. Split it in two. Then split the problematic half in two. Then split
the problematic quarter in two. Then the problematic eigth. And so on.

In no time at all, you will locate the specific part in your init file that
leads to your problem - no matter how big the file is. When you start doing
this, it might seem primitive, but it soon takes off. The key is to have a quick
way to comment out and uncomment a section of code. (Alternatively, you can use
`eval-region'.)

Re: byte-compile making erroneous *Compile Log*

[David Vanderschel]

Drew Adams <drew.adams <at> oracle.com> writes:

DV wrote:
> > My initialization is a bit too large to try to narrow it down
> > by partial execution...
 
> No, it's not too large. What you need to do (unless someone here has
> a direct answer for your problem) is to look for the problem using
> _binary_ search.

Yes, I am familiar with binary search; and, in this case, it will be
my last resort.  My initialization file is over 3000 lines long, so
successive halving still takes a while to get down to something
specific.  Such binary search works well when the problem is an
execution bug, as the 'test' is very quick.  However, in this case,
testing whether the problem still exists at each stage is not at all
trivial.  That is why I am hoping that someone can help me come at
this problem with better insight - which I believe is possible for this
particular problem.

> ... (Alternatively, you can use  `eval-region'.)

Indeed.  That is, in fact, how I have normally done it.  
Too many times.  :(

Re: byte-compile making erroneous *Compile Log*

[martin rudalics]

 > The first part is a link into the file and that works fine.  However, if the
 > 'error' is found in a defun, I get something like the following:
 >
 >    In dv-java-keys:  eemacs.el:223:9:Warning: assignment to free variable
 >     `c-basic-offset'
 >
 > and then the link does not work, because the follower logic believes that the
 > "In <defun-name>" is part of the file name.

Have you set `byte-compile-error-on-warn' to a non-nil value?

martin

Re: byte-compile making erroneous *Compile Log*

[David Vanderschel]

martin rudalics <rudalics <at> gmx.at> writes:

> Have you set `byte-compile-error-on-warn' to a non-nil value?

No.  It is still nil.

I just downloaded emacs-snapshot for Emacs 23 and the problem still exists. 
Rather than try to figure out what was causing it, I have implemented a simple
program that goes into the *Compile-Log* buffer and fixes the problem by
inserting the missing newlines before the file name.  I had not realized it
initially, but some of the "In <defun-name>" log entries do appear correctly on
their own lines.

Re: byte-compile making erroneous *Compile Log*

[martin rudalics]

 > I just downloaded emacs-snapshot for Emacs 23 and the problem still exists.
 > Rather than try to figure out what was causing it, I have implemented a simple
 > program that goes into the *Compile-Log* buffer and fixes the problem by
 > inserting the missing newlines before the file name.  I had not realized it
 > initially, but some of the "In <defun-name>" log entries do appear correctly on
 > their own lines.

So IMHO the only possible culprit is the call to `fill-region' in
`display-warning' which goes as:

	  (when (and warning-fill-prefix (not (string-match "\n" message)))
	    (let ((fill-prefix warning-fill-prefix)
		  (fill-column 78))
	      (fill-region start (point))))

Please try to edebug `fill-region' (with the *Compile-Log* buffer
displayed in some window to see what's going on).  I suppose one of
your .emacs settings wrt to filling cause the behavior you observe.

martin

Re: byte-compile making erroneous *Compile Log*

[David Vanderschel]

martin rudalics <rudalics <at> gmx.at> writes:

> Please try to edebug `fill-region' (with the *Compile-Log* buffer
> displayed in some window to see what's going on).  I suppose one of
> your .emacs settings wrt to filling cause the behavior you observe.

I did (edebug-on-entry (quote fill-region) nil) and the debugger did not start,
so I must be missing something.  (E.g., do I have to recompile fill-region with
debugging enabled, or something like that?)

Looking for "fill" in my initialization I found that
fill-individual-varying-indent and paragraph-ignore-fill-prefix were set to t. 
However, setting both to nil did not help.  I did not see anything else that
looks like suspicious.

I am satisfied with my workaround, which took remarkably little code.  However,
Martin, if you are trying to debug this, I'll continue to pursue it for you -
just give me another clue.

(Incidentally, I had poked around in the byte compiler code trying to find where
it was inserting the warnings - and I could not find it.  At least Martin has
pointed me to where it happens now.)

Re: byte-compile making erroneous *Compile Log*

[martin rudalics]

 > I did (edebug-on-entry (quote fill-region) nil) and the debugger did not start,
 > so I must be missing something.  (E.g., do I have to recompile fill-region with
 > debugging enabled, or something like that?)

Sorry, I should have told you.  Try

M-x find-function RET fill-region RET

followed by C-u C-M-x which calls `edebug-defun` and is also on the
Emacs-Lisp menu.

 > Looking for "fill" in my initialization I found that
 > fill-individual-varying-indent and paragraph-ignore-fill-prefix were set to t.
 > However, setting both to nil did not help.  I did not see anything else that
 > looks like suspicious.

Let's see what happens when you debug this with and without your .emacs
(obviously the bug may be caused by something else than filling).

 > I am satisfied with my workaround, which took remarkably little code.  However,
 > Martin, if you are trying to debug this, I'll continue to pursue it for you -
 > just give me another clue.

I hope `edebug-defun' works for you.  You can use the following function

(defun make-empty-compile-log ()
   (interactive)
   (let ((inhibit-read-only t))
     (with-current-buffer (get-buffer-create "*Compile-Log*")
       (delete-region (point-min) (point-max))
       (display-buffer (current-buffer)))))

to create, empty and display the *Compile-Log* buffer.

Here I can't do anything because I have no recipe to reproduce your bug.

 > (Incidentally, I had poked around in the byte compiler code trying to find where
 > it was inserting the warnings - and I could not find it.  At least Martin has
 > pointed me to where it happens now.)

It's a bit tricky indeed.  `display-warning' which is in the file
warnings.el has the call

	  (if warning-prefix-function
	      (setq level-info (funcall warning-prefix-function
					level level-info)))

where `warning-prefix-function' is set by `byte-compile-log-warning' to
`byte-compile-warning-prefix'.  If you edebug-defun both
`display-warning' and `byte-compile-warning-prefix' you can observe how
these functions and the "funcall" interact when compiling a file.

martin

Re: byte-compile making erroneous *Compile Log*

[David Vanderschel]

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 <defun-name>:  "
>> 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 <defun>: " 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
<defun-name>:" 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.

Re: byte-compile making erroneous *Compile Log*

[martin rudalics]

 >> 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 <defun>: " 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
 > <defun-name>:" 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

Re: byte-compile making erroneous *Compile Log*

[David Vanderschel]

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
>  > <defun-name>:" 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.

Re: byte-compile making erroneous *Compile Log*

[martin rudalics]

 > 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