unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
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…





  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).