bug#20256: 25.0.50; css-mode: filling multi-line comments

[Stefan Monnier <monnier@iro.umontreal.ca>]

> Ah, thanks, I missed that. An updated patch follows. It defines
> `css-adaptive-fill' buffer-locally, which makes `auto-fill-mode'
> behave nice.

Thanks, looks good.

> `css-fill-paragraph' should now be general again.

Not quite: for example a comment starter may fail to match (regexp-quote
comment-start), in modes where comments can be of several different
forms (e.g. some modes might accept both (*...*) and /*...*/ for example).

> +    (when (save-excursion
> +            (back-to-indentation)
> +            (looking-at (regexp-quote comment-start)))

This should probably use comment-start-skip (or comment-search-forward).

> -                     (concat "\\(?:[ \t]*" (regexp-quote comment-continue)
> +                     (concat "\\(?:[ \t]*"
> +                             (regexp-opt
> +                              (list comment-continue comment-start
> +                                    comment-end))

I think this should not use comment-end if it's the empty string
(otherwise the regexp might trigger pathological behavior of our
backtracking-based matcher).
Maybe better would be to use comment-start-skip and comment-end-skip
rather than comment-start and comment-end.

> +(defun scss-fill-paragraph (&optional justify)
> +  "Call `css-fill-paragraph', but ensure that the multi-line
> +   variants of `comment-start' and `comment-end' are in use, in
> +   order to support multi-line comment filling in SCSS mode as
> +   well."
> +  (let ((comment-start "/*")
> +        (comment-end "*/"))
> +    (css-fill-paragraph justify)))

Once you fix the code to use comment-start/end-skip instead of
comment-start/end, this function should be unneeded.


        Stefan