[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