From: "Kévin Le Gouguec" <kevin.legouguec@gmail.com>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: 41810@debbugs.gnu.org, Stephen Berman <stephen.berman@gmx.net>
Subject: bug#41810: 28.0.50; [ELPA] adaptive-wrap: Fontify wrap-prefix
Date: Fri, 12 Jun 2020 10:50:06 +0200 [thread overview]
Message-ID: <87bllovfb5.fsf@gmail.com> (raw)
In-Reply-To: <jwv1rml8cev.fsf-monnier+emacs@gnu.org> (Stefan Monnier's message of "Thu, 11 Jun 2020 18:42:26 -0400")
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…
next prev parent reply other threads:[~2020-06-12 8:50 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-11 16:16 bug#41810: 28.0.50; [ELPA] adaptive-wrap: Fontify wrap-prefix Kévin Le Gouguec
2020-06-11 22:42 ` Stefan Monnier
2020-06-12 8:50 ` Kévin Le Gouguec [this message]
2020-06-12 15:33 ` Stefan Monnier
2020-06-12 22:48 ` Kévin Le Gouguec
2020-06-21 15:34 ` bug#41810: [PATCH][ELPA] " Kévin Le Gouguec
2020-06-21 18:32 ` Basil L. Contovounesios
2020-06-21 22:01 ` Kévin Le Gouguec
2020-08-14 17:15 ` Lars Ingebrigtsen
2020-08-14 17:58 ` Kévin Le Gouguec
2020-08-14 17:59 ` Lars Ingebrigtsen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87bllovfb5.fsf@gmail.com \
--to=kevin.legouguec@gmail.com \
--cc=41810@debbugs.gnu.org \
--cc=monnier@iro.umontreal.ca \
--cc=stephen.berman@gmx.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).