bug#66670: [PATCH] Use buffer-local comment-continue in comment-indent-new-line

[Spencer Baugh <sbaugh@janestreet.com>]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>                       ;; Recreate comment-continue from comment-start.
>> -                     ;; FIXME: wrong if comment-continue was set explicitly!
>>                       ;; FIXME: use prev line's continuation if available.
>> -                     (comment-continue nil))
>> +                     (comment-continue (if (local-variable-p 'comment-continue)
>> +                                           comment-continue
>> +                                         nil)))
>
> Are you sure?  `comment-continue` is very rarely set globally.
> Usually it's set buffer-locally by `comment-normalize-vars`.

Or by the major-mode!  But yes, I see your point, this patch is
effectively removing the (comment-continue nil) definition.

I guess that the (comment-continue nil) definition is there in the first
place so that comment-normalize-vars recalculates it based on
comment-start, which is the comment prefix from the previous line?  So
we therefore copy the prefix from the previous line?

Should we just recalculate comment-continue directly in
comment-indent-new-line instead, if necessary?

Although even if we did that, I don't see any clear way to know that we
should use the configured comment-continue instead of trying to copy the
previous line.  Should we maybe just not copy the comment prefix from
the previous line at all, if comment-continue is non-nil?

>> +(ert-deftest local-comment-continue-in-comment-indent-new-line ()
>> +  (with-temp-buffer
>> +    (setq-local comment-start "/* ")
>> +    (setq-local comment-end "*/")
>                                ^^
> Out of symmetry, I'd have expected a SPC here.
>
>> +    (insert "foo")
>> +    (newline)
>> +    (insert "bar")
>> +    (forward-line -1)
>> +    (end-of-line)
>> +    (comment-region (point-min) (point-max))
>> +    (should (equal (thing-at-point 'line) "/* foo\n"))
>> +    (comment-indent-new-line)
>
> You should also test it with that very same comment but when
> `comment-start` and `comment-end` have been set to something like
> "// " and "".

Will do.