all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Jason Vas Dias <jason.vas.dias@gmail.com>
To: Lars Ingebrigtsen <larsi@gnus.org>
Cc: 51757@debbugs.gnu.org
Subject: bug#51757: 27.2; [patch] man.el : wait for all man(1) output to be buffered before fontifying
Date: Thu, 11 Nov 2021 12:08:14 +0000	[thread overview]
Message-ID: <CALyZvKyH7jDLiOtAPkD2ys=iLacp-3CO78_ZWaqPn_+=jS+-zQ@mail.gmail.com> (raw)
In-Reply-To: <CALyZvKzTUPBSQEYqJ0DmJG=mVvydQ38F8hbi9uPG9YJ9rdRT1A@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2472 bytes --]

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 .

Best Regards,
Jason



On 11/11/2021, Jason Vas Dias <jason.vas.dias@gmail.com> wrote:
> Good day Lars -
>
>    Thanks,  I will test with the man.el from Emacs 28 .
>
>    But if it still does fontification on the fly, for each
>    buffer read, I suspect it will still have the problem -
>    there is no guarantee that the buffer did not end
>    with only a partial escape sequence, which is
>    then ignored.
>
>    Unless this situation is detected and handled
>    (check for partial escape at end, remove it,
>     prefix it to the next buffer read)
>    then it will still occur.
>    I thought it much more complicated to try
>    to do that than to just wait until the complete
>    man process output has been read, then
>    fontify the buffer - much simpler, it always
>    works, only a brief display of unfontified contents
>    for long man-pages occurs.
>
>   I'll grab just the man.el from Emacs 28 and give it
>   a try - I don't want to mess around with RPM
>   packaging & building now to build the whole
>   thing, I'll wait for the Fedora package to come out.
>
> Thanks & Best Regards,
> Jason
>
>
>
> On 11/11/2021, Lars Ingebrigtsen <larsi@gnus.org> wrote:
>> "Jason Vas Dias"<jason.vas.dias@gmail.com> writes:
>>
>>>   Render a LONG manual page, for instance :
>>>
>>>       M-x manual-entry bash
>>>
>>>   ALWAYS triggers this bug for me, on a Fedora 34 x86_64 Linux distro,
>>>   fully up-to-date as of 2021-11-11 -
>>>
>>>       $ rpm -q emacs
>>>       emacs-27.2-5.fc34.x86_64
>>
>> I think these ANSI glitches have been fixed in Emacs 28.  Would it be
>> possible for you to build that and check?
>>
>> --
>> (domestic pets only, the antidote for overdose, milk.)
>>    bloggy blog: http://lars.ingebrigtsen.no
>>
>

[-- Attachment #2: Emacs_27.2_Man_Bash_2021-11-11_12-01-47.png --]
[-- Type: image/png, Size: 367353 bytes --]

  parent reply	other threads:[~2021-11-11 12:08 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-10 23:45 bug#51757: 27.2; [patch] man.el : wait for all man(1) output to be buffered before fontifying Jason Vas Dias
2021-11-11  3:51 ` Lars Ingebrigtsen
2021-11-11 11:36   ` Jason Vas Dias
2021-11-11 11:51     ` Lars Ingebrigtsen
2021-11-11 12:08     ` Jason Vas Dias [this message]
2021-11-11 12:09       ` Lars Ingebrigtsen
2021-11-11 15:05       ` Eli Zaretskii
2021-11-11 17:35         ` Juri Linkov
     [not found]           ` <CALyZvKxJppsmxTPY7+Gzhc82eYY-a6cCdL25cQ23KbdD=RUU_Q@mail.gmail.com>
2021-11-12 15:50             ` Jason Vas Dias
2021-11-12 15:54               ` Jason Vas Dias
2021-11-13 17:38                 ` Juri Linkov
2021-11-15 23:06 ` Dan Čermák
2021-11-16  3:28   ` Eli Zaretskii
2021-12-23 10:24     ` 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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CALyZvKyH7jDLiOtAPkD2ys=iLacp-3CO78_ZWaqPn_+=jS+-zQ@mail.gmail.com' \
    --to=jason.vas.dias@gmail.com \
    --cc=51757@debbugs.gnu.org \
    --cc=larsi@gnus.org \
    /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 external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.