bug#51757: 27.2; [patch] man.el : wait for all man(1) output to be buffered before fontifying

[Jason Vas Dias]

Oops, I meant:
$ rpm -q emacs man-db groff-base
emacs-27.2-5.fc34.x86_64
man-db-2.9.3-3.fc34.x86_64
groff-base-1.22.4-7.fc34.x86_64

unless you are running these versions, with the Red Hat patches,
you may not see this bug.


On 12/11/2021, Jason Vas Dias <jason.vas.dias@gmail.com> wrote:
> ---------- Forwarded message ----------
> From: Jason Vas Dias <jason.vas.dias@gmail.com>
> Date: Fri, 12 Nov 2021 15:49:20 +0000
> Subject: Re: bug#51757: 27.2; [patch] man.el : wait for all man(1)
> output to be buffered before fontifying
> To: Juri Linkov <juri@linkov.net>
>
> What version of Emacs / man / groff are you running ?
> Mine are:
>   $ rpm -q emacs man groff-base
> emacs-27.2-5.fc34.x86_64
> package man is not installed
> groff-base-1.22.4-7.fc34.x86_64
>
> Are you using the Red Hat patches to Emacs ?
> If not, it may be an RH patch related thing.
> It happens 100% every time loading the bash manpage for
> me, at the same places in the file.
>
> Thanks & Best Regards,
> Jason
>
> On 11/11/2021, Juri Linkov <juri@linkov.net> wrote:
>>>> Of course, with the man.el from emacs-28, I get the error:
>>>>   'completing-read: Symbol’s function definition is void:
>>>> format-prompt'
>>>> under Emacs-27.2 , which is NOT Emacs-28 :-( .
>>>>
>>>> If you can do 'M-x manual-entry bash' in Emacs-28, and
>>>> it never misses a font transition, let me know - I will
>>>> re-examine once Fedora's Emacs 28 comes out.
>>>>
>>>> But I enclose a screenshot of how the bash manpage looks with the
>>>> Emacs 27.2 man.el, with all the remaining text of the man-page
>>>> after the start of the 'PARAMETERS' section in bold, because
>>>> only a partial escape sequence was at the end of the buffer
>>>> and the transition was missed by fontification-on-the-fly .
>>>
>>> I just did that, and I see no problems with the font transitions.
>>
>> Maybe reproducibility depends on the value of 'read-process-output-max'?
>> But I tried to set it to a very small value (100), and still no ANSI
>> sequence was emitted partially between font-lock iterations.
>>
>