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