GNU bug report logs - #46804
27.1; Man page for git-config(1) is partly displayed in overstriked font

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 46804 in the body.
You can then email your comments to 46804 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Tim Landscheidt <tim <at> tim-landscheidt.de>
To: bug-gnu-emacs <at> gnu.org
Subject: 27.1; Man page for git-config(1) is partly displayed in overstriked
 font
Date: Fri, 26 Feb 2021 22:10:56 +0000

Severity: minor

On (my) Fedora 32:

| emacs -Q --eval '(man "1 git-config")'

causes the part of the man page for git-config(1) from the
section title "CONFIGURATION FILE" to the word "prereceive"
in the entry for "receive.certNonceSlop" to be displayed in
overstriked font.

This is probably related to (or the same as?) bug #36927.

I understand that it is, eh, non-trivial to fix this asyn-
chronous chunked fontification, especially for minor cosme-
tical gain.  But perhaps it would be possible to append each
received chunk to another, "back" buffer, then, when the
process has ended and there was more than one chunk, fontify
that buffer and copy its contents to the "front" buffer, and
in both cases delete the "back" buffer.  (There might be a
more "correct" approach to replace the destructive
backward-delete-char calls & Co. with marking some text as
invisible, so the original input is not lost, but I'm more
interested in the output :-).)

Message #8 received at 46804 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Tim Landscheidt <tim <at> tim-landscheidt.de>
Cc: 46804 <at> debbugs.gnu.org
Subject: Re: bug#46804: 27.1; Man page for git-config(1) is partly displayed
 in overstriked font
Date: Sat, 27 Feb 2021 05:50:40 +0100

Tim Landscheidt <tim <at> tim-landscheidt.de> writes:

> Severity: minor
>
> On (my) Fedora 32:
>
> | emacs -Q --eval '(man "1 git-config")'
>
> causes the part of the man page for git-config(1) from the
> section title "CONFIGURATION FILE" to the word "prereceive"
> in the entry for "receive.certNonceSlop" to be displayed in
> overstriked font.

I'm unable to reproduce this on Debian/bullseye -- the manual here
doesn't have the word "prereceive" in it, apparently...

> I understand that it is, eh, non-trivial to fix this asyn-
> chronous chunked fontification, especially for minor cosme-
> tical gain.  But perhaps it would be possible to append each
> received chunk to another, "back" buffer, then, when the
> process has ended and there was more than one chunk, fontify
> that buffer and copy its contents to the "front" buffer, and
> in both cases delete the "back" buffer.  (There might be a
> more "correct" approach to replace the destructive
> backward-delete-char calls & Co. with marking some text as
> invisible, so the original input is not lost, but I'm more
> interested in the output :-).)

I'm not very familiar with man.el fontification, but it uses ansi-color
for fontification.  And that got the following change in Emacs 28:

commit 2e2a8e5491bc6259a9ebe8c703c1c501307953e2
Author:     Jim Blandy <jimb <at> red-bean.com>
AuthorDate: Tue Oct 20 13:09:16 2020 +0200

    Man highlighting: Don't occasionally bold entire sections.
    
    * lisp/ansi-color.el (ansi-color-apply-on-region): Always save a
    restart position in ansi-color-context-region if the region ends with
    highlighting active.

So it's possible what you're seeing has been fixed in Emacs 28.  Would
it be possible for you to build the development version of Emacs and see
whether the problem is still present there?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #13 received at 46804 <at> debbugs.gnu.org (full text, mbox):

From: Tim Landscheidt <tim <at> tim-landscheidt.de>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 46804 <at> debbugs.gnu.org
Subject: Re: bug#46804: 27.1; Man page for git-config(1) is partly displayed
 in overstriked font
Date: Sun, 28 Feb 2021 05:33:53 +0000

Lars Ingebrigtsen <larsi <at> gnus.org> wrote:

>> On (my) Fedora 32:

>> | emacs -Q --eval '(man "1 git-config")'

>> causes the part of the man page for git-config(1) from the
>> section title "CONFIGURATION FILE" to the word "prereceive"
>> in the entry for "receive.certNonceSlop" to be displayed in
>> overstriked font.

> I'm unable to reproduce this on Debian/bullseye -- the manual here
> doesn't have the word "prereceive" in it, apparently...

Well, if I had copied & pasted "pre-receive" correctly … :-)
(NB: I could /not/ reproduce this in a Debian Buster contai-
ner.)

> […]

> I'm not very familiar with man.el fontification, but it uses ansi-color
> for fontification.  And that got the following change in Emacs 28:

> commit 2e2a8e5491bc6259a9ebe8c703c1c501307953e2
> Author:     Jim Blandy <jimb <at> red-bean.com>
> AuthorDate: Tue Oct 20 13:09:16 2020 +0200

>     Man highlighting: Don't occasionally bold entire sections.

>     * lisp/ansi-color.el (ansi-color-apply-on-region): Always save a
>     restart position in ansi-color-context-region if the region ends with
>     highlighting active.

> So it's possible what you're seeing has been fixed in Emacs 28.  Would
> it be possible for you to build the development version of Emacs and see
> whether the problem is still present there?

I have tested master and it works, and then backported
2e2a8e5491bc6259a9ebe8c703c1c501307953e2 to 27.1, and it
fixes the issue.

Message #16 received at 46804 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Tim Landscheidt <tim <at> tim-landscheidt.de>
Cc: 46804 <at> debbugs.gnu.org
Subject: Re: bug#46804: 27.1; Man page for git-config(1) is partly displayed
 in overstriked font
Date: Sun, 28 Feb 2021 14:49:19 +0100

Tim Landscheidt <tim <at> tim-landscheidt.de> writes:

> Well, if I had copied & pasted "pre-receive" correctly … :-)

:-)

>> So it's possible what you're seeing has been fixed in Emacs 28.  Would
>> it be possible for you to build the development version of Emacs and see
>> whether the problem is still present there?
>
> I have tested master and it works, and then backported
> 2e2a8e5491bc6259a9ebe8c703c1c501307953e2 to 27.1, and it
> fixes the issue.

Be aware, though, that that patch leads to severe regressions in eshell
(and sometimes in shell mode, too) -- you need f1fa35f0914f to fix that
problem.

And I'm not 100% sure about the fix in f1fa35f0914f, so backporting
these two things to Emacs 27 is out of scope, I think.  (We're only
fixing regressions in Emacs 27 now, and this man.el problem was also
present in Emacs 26, if I remember correctly.)  So this won't be fixed
in Emacs 27, but is fixed in Emacs 28, and I'm closing this bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

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