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

[martin rudalics]

> 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.