Re: adaptive-fill-mode and auto-fill-mode

[martin rudalics <rudalics@gmx.at>]

 > I guess what I don't understand is in what way this is a fix for
 > the problem.  Yes, it may work for your specific case, but what about in
 > cases such as:
 >
 >   (defun foo ()
 >     "docstring"
 >
 >     ;; The empty line above is important.
 >     ;; This second line as well.
 >     (let ((toto titi))
 >       ;; some comment klsdhfkshgkslfkhgsjkhgskhgjfdhgd yy
 >
 > the same problem will happen, although not at BOL.

I don't accept the prefix when _compos_ is not at BOL (in your example
compos is before ";; some comment ...").  `comment-indent-new-line' has
no idea where the fill-prefix comes from (otherwise solving all this
would be trivial).  I'm afraid my code is unreadable.

 >  Maybe a better fix would
 > be (when compos is set and `prefix' matches
 > (concat "\\`[ \t]*" comment-start-skip)) to go to compos, and call
 > comment-forward until we reach point.  If we bump into non-comment before
 > reaching point, then the prefix was set based on some other unrelated
 > comment and should be ignored.

Why?  compos is at the beginning of the current comment provided `point'
is within a comment.  The problem that `comment-indent-new-line' used
the fill-prefix in the "not compos" case is trivially handled in the
"else" part of `comment-valid-prefix-p'.  The problem you refer to is
with the "then" part.

 >>Indeed.  The reason is that I don't want to affect multiline comment
 >>environments when the comment starting at compos is a single line
 >>comment.
 >
 >
 > But in what is checking comment-end better than using "comment-forward + not
 > bolp"?

Well, checking comment-end style is cheaper than doing comment-forward.
Combine these before doing the string-match?

 >>>;; foo wrote:
 >>>;; > where the fill-prefix will include 3 spaces after ";;"
 >>>;; > even though the first line doesn't match it.
 >
 >
 >>Do you think my patch would be responsible for not handling these
 >
 >
 > The prefix would be ";; >" which doesn't match the string at compos, so your
 > code would reject it.

... but the string at compos is ";; >" ...

 >>(at line-beginning)?
 >
 >
 > These can happen at any indentation.

... if compos is not at line beginning the prefix is rejected.

 >>If the prefix passed to `comment-valid-prefix-p'
 >>matches the string at compos there shouldn't be any problems.
 >
 >
 > Of course, but what I'm saying is that it may not match, even in cases where
 > it's perfectly correct.

The only cases rejected are when the string is not at line beginning or
does not match the prefix.  In your second example the prefix is ";; ",
at least with emacs -Q, because that's the common prefix of ";; " and
";; >".

 >>I think the second example doesn't work because
 >>`fill-common-string-prefix' determines the common prefix of ";; " and
 >>";; > " as ";; " long before I lay my hands at this.
 >
 >
 > That depends on adaptive-fill-function.

I fail to understand you here.  If the comment at compos doesn't match
the prefix why should I want to insert the prefix on the next line?

 >>Where do you want to strip whitespace,
 >>before the comment marker, between comment marker and body?  Would it be
 >>reliable to do that?
 >
 >
 > Why not?

Because, as I suppose, the number of spaces is significant for the
fill-prefix.

 >>Personally, I don't care at all.  My auto-fill-function uses syntax-ppss
 >>and doesn't fill normal strings.  But, as stated above, I don't think
 >>that auto-fill should be allowed to break non-doc-strings in Elisp.
 >
 >
 > I completely understand your point of view, but it's still far from
 > a bug-fix and it's not the only way to go about it.

It fixes that better than I expected.  Note also that you never had a
chance to handle this _before_ the introduction of the doc-string face.
But I admit that emacs was always breaking lisp strings this way, hence
let's drop it (which means I don't need to change fill.el either).

 > Have you tried
 > comment-auto-fill-only-comments?

It doesn't fill doc-strings.