bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Stefan Monnier
Subject: bug#41810: 28.0.50; [ELPA] adaptive-wrap: Fontify wrap-prefix
Date: Fri, 12 Jun 2020 11:33:25 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

> 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

Ah, indeed, it's because we go through `string-to-char` which has no way
to preserve the text properties.
Yes, we should fix that to just concatenate `adaptive-wrap-extra-indent`
times the string returned by (substring (fill-context-prefix beg end) -1).

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

We should be able to make this work by trying to preserve
`first-line-prefix`s text properties somehow.

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

I don't think it could be fixed in `fill-context-prefix`.

I guess we could try and fix it in `adaptive-wrap-fill-context-prefix`
by trying to preserve any face that covers the whole line (including the
final newline).

I'm glad I'm not the one who'll write the code ;-)


        Stefan






reply via email to

[Prev in Thread] Current Thread [Next in Thread]