bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#46804: 27.1; Man page for git-config(1) is partly displayed in overs


From: Lars Ingebrigtsen
Subject: 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
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Tim Landscheidt <tim@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@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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]