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