bug#41810: 28.0.50; [ELPA] adaptive-wrap: Fontify wrap-prefix

[Kévin Le Gouguec]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> The comment's continuation line starts with ";;;;".  I see two problems
>> with this:
>>
>> 1. The padding characters are not propertized, so we get two fontified
>>    semicolons, then two unfontified semicolons.
>
> That looks ugly, indeed.  IIRC the reason is that when we extract the
> prefix from the buffer, font-lock hasn't applied its `face` text
> property yet.

Or has it?  The string returned by fill-context-prefix *has* the correct
face, that's why the first two semicolons are fontified IIUC; only the
*extra* padding characters are unfontified, those that we generate with:

#+begin_src
;; Reconstructed from `adaptive-wrap-fill-context-prefix':
(make-string
 adaptive-wrap-extra-indent
 (string-to-char (substring (fill-context-prefix beg end) -1)))
#+end_src

I think font-lock is not to blame here, if we want those extra
characters to be fontified, we'll have to apply the face ourselves…

>> 2. Visually, this looks sort of cluttered.  I have searched Debbugs and
>>    emacs-devel for a rationale for using (substring fcp -1) instead of
>>    unconditionally using spaces, but I could not find any.
>
> I think it just seemed like a good idea.  I suspect it's a matter of taste.
> Not sure if it's important enough to justify offering both behaviors.

Mmm.  Well obviously, I'm biased toward unconditionally using spaces for
the extra-indent characters, so the resolutions I can imagine, in
decreasing order of personal preference, are:

1. Consensus that letting continuation lines breathe is optimal
   ⇒ spaces

2. Agreement that it's a matter of taste
   ⇒ defcustom accepting a char or a symbol (last-fcp-char?), defaulting
     to the latter

3. "There is a very good reason for repeating the last
    fill-context-prefix character extra-indent times: for example,
    consider the case when…"
   ⇒ OK then!

Honestly, as much as I'd like spaces, I'd settle for (substring fcp -1)
as long as we fix the fontification problem.

>> See second screenshot, taken from emacs -Q -rv, with:
>
> That's ugly, indeed.  Not sure whether the problem really comes from nor
> where it should be fixed, but it's clearly a bug.

I think I narrowed it down to this condition in fill-context-prefix:

#+begin_src
                   (if (or (and first-line-regexp
                                (string-match first-line-regexp
                                              first-line-prefix))
                           (and comment-start-skip
                                (string-match comment-start-skip
                                              first-line-prefix)))
                       first-line-prefix
                     (make-string (string-width first-line-prefix) ?\s))
#+end_src

In the *scratch* buffer, the condition holds true, so first-line-prefix
is returned, text properties and all: that's why the first two
semicolons are fontified.

In a diff buffer,

1. for removed lines, the condition is false, so we make a new,
   unfontified string, without the diff-removed face,

2. for added lines and headers, there is no prefix at all, so
   fill-context-prefix has nothing to tell us about what faces to apply.

I don't know if the fix belongs in fill-context-prefix, or if it should
be adaptive-wrap-fill-context-prefix's job to fixup faces…