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.