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

Previous Next

Full log

View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
Cc: 41810 <at> debbugs.gnu.org, Stephen Berman <stephen.berman <at> gmx.net>
Subject: bug#41810: 28.0.50; [ELPA] adaptive-wrap: Fontify wrap-prefix
Date: Fri, 12 Jun 2020 11:33:25 -0400

> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.