[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#41810: 28.0.50; [ELPA] adaptive-wrap: Fontify wrap-prefix
From: |
Kévin Le Gouguec |
Subject: |
bug#41810: 28.0.50; [ELPA] adaptive-wrap: Fontify wrap-prefix |
Date: |
Fri, 12 Jun 2020 10:50:06 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) |
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…
- bug#41810: 28.0.50; [ELPA] adaptive-wrap: Fontify wrap-prefix, Kévin Le Gouguec, 2020/06/11
- bug#41810: 28.0.50; [ELPA] adaptive-wrap: Fontify wrap-prefix, Stefan Monnier, 2020/06/11
- bug#41810: 28.0.50; [ELPA] adaptive-wrap: Fontify wrap-prefix,
Kévin Le Gouguec <=
- bug#41810: 28.0.50; [ELPA] adaptive-wrap: Fontify wrap-prefix, Stefan Monnier, 2020/06/12
- bug#41810: 28.0.50; [ELPA] adaptive-wrap: Fontify wrap-prefix, Kévin Le Gouguec, 2020/06/12
- bug#41810: [PATCH][ELPA] adaptive-wrap: Fontify wrap-prefix, Kévin Le Gouguec, 2020/06/21
- bug#41810: [PATCH][ELPA] adaptive-wrap: Fontify wrap-prefix, Basil L. Contovounesios, 2020/06/21
- bug#41810: [PATCH][ELPA] adaptive-wrap: Fontify wrap-prefix, Kévin Le Gouguec, 2020/06/21