GNU bug report logs - #17831
24.4.50; bad default value for `Man-width'

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 17831 in the body.
You can then email your comments to 17831 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: Leo Liu <sdl.web <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.4.50; bad default value for `Man-width'
Date: Sun, 22 Jun 2014 21:30:45 +0800

Man-width defaults to the window width at the time of running `man'. But
if the frame is split horizontally it usually leads to a view with the
right-hand-side half unviewable.

Leo

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Leo Liu <sdl.web <at> gmail.com>
Cc: 17831 <at> debbugs.gnu.org
Subject: Re: bug#17831: 24.4.50; bad default value for `Man-width'
Date: Mon, 23 Jun 2014 08:53:45 -0400

forcemerge 17831 2588
thanks

> Man-width defaults to the window width at the time of running `man'.  But
> if the frame is split horizontally it usually leads to a view with the
> right-hand-side half unviewable.

Indeed.
As discussed earlier, I think the right fix is to display the buffer
right away and then fill it in the background.

Problem with it, is that currently we do "fill the buffer with
half-processed text; finish formatting; display", so if we only move the
"display" part, the user will see (temporarily) the half-processed text.


        Stefan

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

From: Leo Liu <sdl.web <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#17831: 24.4.50; bad default value for `Man-width'
Date: Tue, 24 Jun 2014 07:21:47 +0800

On 2014-06-23 08:53 -0400, Stefan Monnier wrote:
> Problem with it, is that currently we do "fill the buffer with
> half-processed text; finish formatting; display", so if we only move the
> "display" part, the user will see (temporarily) the half-processed text.

Indeed. On the other hand simply change the default value to 80 always
gives me a more readable output. But this doesn't fix the wrong
behaviour when using window width.

Leo

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

From: Juri Linkov <juri <at> jurta.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 17831 <at> debbugs.gnu.org, Leo Liu <sdl.web <at> gmail.com>
Subject: Re: bug#17831: 24.4.50; bad default value for `Man-width'
Date: Tue, 24 Jun 2014 02:17:51 +0300

>> Man-width defaults to the window width at the time of running `man'.  But
>> if the frame is split horizontally it usually leads to a view with the
>> right-hand-side half unviewable.
>
> Indeed.
> As discussed earlier, I think the right fix is to display the buffer
> right away and then fill it in the background.
>
> Problem with it, is that currently we do "fill the buffer with
> half-processed text; finish formatting; display", so if we only move the
> "display" part, the user will see (temporarily) the half-processed text.

While testing the changes for bug#17809 I noticed a similar problem for
the *Completions* buffer.  It's filled with completions using the
default width of 80 columns while the buffer is not yet displayed.
Later when the buffer is displayed in a window with the frame's full-width
of 160 columns, it leaves too much empty space in the buffer.

As a general solution for such cases it seems the proper order is
to display an empty buffer first, and then fill it with the contents.

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Juri Linkov <juri <at> jurta.org>
Cc: 17831 <at> debbugs.gnu.org, Leo Liu <sdl.web <at> gmail.com>
Subject: Re: bug#17831: 24.4.50; bad default value for `Man-width'
Date: Mon, 23 Jun 2014 21:26:15 -0400

> As a general solution for such cases it seems the proper order is
> to display an empty buffer first, and then fill it with the contents.

Agreed.


        Stefan

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

From: martin rudalics <rudalics <at> gmx.at>
To: Juri Linkov <juri <at> jurta.org>, 
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 17831 <at> debbugs.gnu.org, Leo Liu <sdl.web <at> gmail.com>
Subject: Re: bug#17831: 24.4.50; bad default value for `Man-width'
Date: Tue, 24 Jun 2014 09:13:54 +0200

> As a general solution for such cases it seems the proper order is
> to display an empty buffer first, and then fill it with the contents.

Obviously there are two way to tackle this:

Fill the buffer in some way and try to display it in a window with
suitable size.  That's what we've done so far and it fails typically
because it looks at the width of the selected window in order to do the
filling but displays the buffer in a window with different width.  The
first to report this problem was Lennart when filing bug#6000 more than
four years ago.

To fix this we could either use some sort of maximimum width (for me
more than 80 columns are not very readable anyway) and propose an
adequate display buffer action or implement simple heuristics to detect
how large the window used by `display-buffer' would be and fill the
buffer in some adequate manner.

Alternatively, we could display the buffer first, look at what size we
get, fill the buffer, and possibly resize the window afterwards.  For
`with-temp-buffer-window' this means that we would have to fill the
buffer either via `temp-buffer-window-show-hook' or in QUIT-FUNCTION.

martin

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Juri Linkov <juri <at> jurta.org>, 17831 <at> debbugs.gnu.org,
 Leo Liu <sdl.web <at> gmail.com>
Subject: Re: bug#17831: 24.4.50; bad default value for `Man-width'
Date: Tue, 24 Jun 2014 08:53:14 -0400

> To fix this we could either use some sort of maximimum width (for me
> more than 80 columns are not very readable anyway) and propose an

I'm with you here, but some users disagree (e.g. they want to use their
160-column *Cmpletions* window fully).

> Alternatively, we could display the buffer first, look at what size we
> get, fill the buffer, and possibly resize the window afterwards.

That's what we should aim for, I think.


        Stefan

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: juri <at> jurta.org, 17831 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca,
 sdl.web <at> gmail.com
Subject: Re: bug#17831: 24.4.50; bad default value for `Man-width'
Date: Tue, 24 Jun 2014 18:46:37 +0300

> Date: Tue, 24 Jun 2014 09:13:54 +0200
> From: martin rudalics <rudalics <at> gmx.at>
> Cc: 17831 <at> debbugs.gnu.org, Leo Liu <sdl.web <at> gmail.com>
> 
> To fix this we could either use some sort of maximimum width (for me
> more than 80 columns are not very readable anyway) and propose an
> adequate display buffer action or implement simple heuristics to detect
> how large the window used by `display-buffer' would be and fill the
> buffer in some adequate manner.

None of this will ever work 100% reliably in the "M-x man" case,
because while the command runs in the background, the user could
change the window and frame configuration at will.

> Alternatively, we could display the buffer first, look at what size we
> get, fill the buffer, and possibly resize the window afterwards.  For
> `with-temp-buffer-window' this means that we would have to fill the
> buffer either via `temp-buffer-window-show-hook' or in QUIT-FUNCTION.

But this will momentarily flash incorrect (e.g., empty) display,
right?  Not nice, IMO.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: rudalics <at> gmx.at, 17831 <at> debbugs.gnu.org, sdl.web <at> gmail.com
Subject: Re: bug#17831: 24.4.50; bad default value for `Man-width'
Date: Tue, 24 Jun 2014 18:55:18 +0300

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Date: Tue, 24 Jun 2014 08:53:14 -0400
> Cc: 17831 <at> debbugs.gnu.org, Leo Liu <sdl.web <at> gmail.com>
> 
> > To fix this we could either use some sort of maximimum width (for me
> > more than 80 columns are not very readable anyway) and propose an
> 
> I'm with you here, but some users disagree (e.g. they want to use their
> 160-column *Cmpletions* window fully).
> 
> > Alternatively, we could display the buffer first, look at what size we
> > get, fill the buffer, and possibly resize the window afterwards.
> 
> That's what we should aim for, I think.

You are talking about 2 different situations as if they are identical.
But IMO they are very different.  "M-x man" runs the text formatter in
the background, while the user is free to change the window
configuration at will.  I see no way that we will be able to solve
this reliably.

By contrast, in the *Completions* use case the code that formats the
text runs synchronously, so having in place some protocol that would
allow to query about the dimensions of the window display-buffer
etc. _will_ get, and then immediately use these dimensions to format
the candidate list, is probably all we need.  The alternative you
favor is IMO worse: it will momentarily flash incorrect display, which
I think will look un-professional.

Returning to the "M-x man" use case, I think the possibilities
supported via the Man-width option is the best we can do.  So any
users that are unhappy should be pointed to that option.

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: juri <at> jurta.org, martin rudalics <rudalics <at> gmx.at>, 17831 <at> debbugs.gnu.org,
 sdl.web <at> gmail.com
Subject: Re: bug#17831: 24.4.50; bad default value for `Man-width'
Date: Tue, 24 Jun 2014 13:31:01 -0400

> But this will momentarily flash incorrect (e.g., empty) display,
> right?  Not nice, IMO.

That doesn't seem to bother users of C-x v =


        Stefan

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rudalics <at> gmx.at, 17831 <at> debbugs.gnu.org, sdl.web <at> gmail.com
Subject: Re: bug#17831: 24.4.50; bad default value for `Man-width'
Date: Tue, 24 Jun 2014 13:33:50 -0400

> By contrast, in the *Completions* use case the code that formats the
> text runs synchronously, so having in place some protocol that would
> allow to query about the dimensions of the window display-buffer
> etc. _will_ get, and then immediately use these dimensions to format
> the candidate list, is probably all we need.  The alternative you
> favor is IMO worse: it will momentarily flash incorrect display, which
> I think will look un-professional.

In the *Completions* case the empty buffer won't be temporarily
displayed (because there's no redisplay going on before it's filled).

The unprofessionalism doesn't bother me too much for M-x man, especially
since the current behavior is broken IMNSHO: it pops up a window
asynchronously, i.e. at a time you might be doing something else and not
expecting this disruption.


        Stefan

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: juri <at> jurta.org, rudalics <at> gmx.at, 17831 <at> debbugs.gnu.org, sdl.web <at> gmail.com
Subject: Re: bug#17831: 24.4.50; bad default value for `Man-width'
Date: Tue, 24 Jun 2014 20:56:16 +0300

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: martin rudalics <rudalics <at> gmx.at>,  juri <at> jurta.org,  17831 <at> debbugs.gnu.org,  sdl.web <at> gmail.com
> Date: Tue, 24 Jun 2014 13:31:01 -0400
> 
> > But this will momentarily flash incorrect (e.g., empty) display,
> > right?  Not nice, IMO.
> 
> That doesn't seem to bother users of C-x v =

Which again uses an asynchronous text producer.  That's not the same
as *Completions*, so I don't think we should discuss these two issues
as one.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: rudalics <at> gmx.at, 17831 <at> debbugs.gnu.org, sdl.web <at> gmail.com
Subject: Re: bug#17831: 24.4.50; bad default value for `Man-width'
Date: Tue, 24 Jun 2014 20:59:08 +0300

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: rudalics <at> gmx.at,  17831 <at> debbugs.gnu.org,  sdl.web <at> gmail.com
> Date: Tue, 24 Jun 2014 13:33:50 -0400
> 
> > By contrast, in the *Completions* use case the code that formats the
> > text runs synchronously, so having in place some protocol that would
> > allow to query about the dimensions of the window display-buffer
> > etc. _will_ get, and then immediately use these dimensions to format
> > the candidate list, is probably all we need.  The alternative you
> > favor is IMO worse: it will momentarily flash incorrect display, which
> > I think will look un-professional.
> 
> In the *Completions* case the empty buffer won't be temporarily
> displayed (because there's no redisplay going on before it's filled).

Are you sure? what about echo-area messages, which might trigger
redisplay?

But if you are right, then this is just another case of what I
suggested, i.e. being able to query Emacs about the dimensions before
actually displaying.

> The unprofessionalism doesn't bother me too much for M-x man, especially
> since the current behavior is broken IMNSHO: it pops up a window
> asynchronously, i.e. at a time you might be doing something else and not
> expecting this disruption.

So perhaps TRT is simply to get rid of the asynchronous operation in
the first place.

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: juri <at> jurta.org, rudalics <at> gmx.at, 17831 <at> debbugs.gnu.org, sdl.web <at> gmail.com
Subject: Re: bug#17831: 24.4.50; bad default value for `Man-width'
Date: Tue, 24 Jun 2014 15:35:04 -0400

>> > But this will momentarily flash incorrect (e.g., empty) display,
>> > right?  Not nice, IMO.
>> That doesn't seem to bother users of C-x v =

Doesn't bother web-browser users either, BTW.

> Which again uses an asynchronous text producer.  That's not the same
> as *Completions*, so I don't think we should discuss these two issues
> as one.

For the non-async case, the empty buffer will not appear for lack
of redisplay.

> Are you sure? what about echo-area messages, which might trigger redisplay?

That can happen, but I wouldn't worry about it.

> > The unprofessionalism doesn't bother me too much for M-x man, especially
> > since the current behavior is broken IMNSHO: it pops up a window
> > asynchronously, i.e. at a time you might be doing something else and not
> > expecting this disruption.
> So perhaps TRT is simply to get rid of the asynchronous operation in
> the first place.

The annoying disruption is when "M-x man" takes a long time to get&generate
the full output.  I.e. it's the case where it's especially important to
use asynchronous operation.


        Stefan

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: juri <at> jurta.org, rudalics <at> gmx.at, 17831 <at> debbugs.gnu.org, sdl.web <at> gmail.com
Subject: Re: bug#17831: 24.4.50; bad default value for `Man-width'
Date: Tue, 24 Jun 2014 23:06:30 +0300

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: rudalics <at> gmx.at,  juri <at> jurta.org,  17831 <at> debbugs.gnu.org,  sdl.web <at> gmail.com
> Date: Tue, 24 Jun 2014 15:35:04 -0400
> 
> > So perhaps TRT is simply to get rid of the asynchronous operation in
> > the first place.
> 
> The annoying disruption is when "M-x man" takes a long time to get&generate
> the full output.

Most of that can easily be thrown away.  Just look at what it does.

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: juri <at> jurta.org, rudalics <at> gmx.at, 17831 <at> debbugs.gnu.org, sdl.web <at> gmail.com
Subject: Re: bug#17831: 24.4.50; bad default value for `Man-width'
Date: Tue, 24 Jun 2014 16:29:48 -0400

>> > So perhaps TRT is simply to get rid of the asynchronous operation in
>> > the first place.
>> The annoying disruption is when "M-x man" takes a long time to get&generate
>> the full output.
> Most of that can easily be thrown away.  Just look at what it does.

Maybe it could be sped up, indeed.
But I still prefer an async process that gives me:
- empty buffer after 0s
- full first page displayed after 0.1s
- buffer fully filled and ready after 5s
over a sync process that blocks for 3s.


        Stefan

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

From: Juri Linkov <juri <at> jurta.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rudalics <at> gmx.at, 17831 <at> debbugs.gnu.org,
 Stefan Monnier <monnier <at> iro.umontreal.ca>, sdl.web <at> gmail.com
Subject: Re: bug#17831: 24.4.50; bad default value for `Man-width'
Date: Wed, 25 Jun 2014 02:42:08 +0300

> Which again uses an asynchronous text producer.  That's not the same
> as *Completions*, so I don't think we should discuss these two issues
> as one.

It's not the same, indeed.  This is why in the previous message
I referred to bug#17809 as a similar problem, but not the same.

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

From: Juri Linkov <juri <at> jurta.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: rudalics <at> gmx.at, Eli Zaretskii <eliz <at> gnu.org>, 17831 <at> debbugs.gnu.org,
 sdl.web <at> gmail.com
Subject: Re: bug#17831: 24.4.50; bad default value for `Man-width'
Date: Wed, 25 Jun 2014 02:48:35 +0300

> But I still prefer an async process that gives me:
> - empty buffer after 0s
> - full first page displayed after 0.1s
> - buffer fully filled and ready after 5s
> over a sync process that blocks for 3s.

This simple patch displays the buffer immediately,
but then slowly fills it with unformatted output
that doesn't look nice.  So maybe better would be to create
a temporary hidden buffer, do formatting in background,
and copy the formatted text to the displayed buffer.

=== modified file 'lisp/man.el'
--- lisp/man.el	2014-05-09 07:02:00 +0000
+++ lisp/man.el	2014-06-24 23:47:12 +0000
@@ -1056,6 +1056,7 @@ (defun Man-getpage-in-background (topic)
       (require 'env)
       (message "Invoking %s %s in the background" manual-program man-args)
       (setq buffer (generate-new-buffer bufname))
+      (Man-notify-when-ready buffer)
       (with-current-buffer buffer
 	(setq buffer-undo-list t)
 	(setq Man-original-frame (selected-frame))

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Juri Linkov <juri <at> jurta.org>
Cc: rudalics <at> gmx.at, Eli Zaretskii <eliz <at> gnu.org>, 17831 <at> debbugs.gnu.org,
 sdl.web <at> gmail.com
Subject: Re: bug#17831: 24.4.50; bad default value for `Man-width'
Date: Tue, 24 Jun 2014 23:11:02 -0400

> This simple patch displays the buffer immediately,
> but then slowly fills it with unformatted output
> that doesn't look nice.

Indeed, that's why I haven't made this change in Emacs years ago (when
I made it in my local copy after getting too annoyed at the window-popup
disruption).  The solution is obvious, tho: "Just" move the reformatting
to the process-filter.


        Stefan

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

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: juri <at> jurta.org, 17831 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca,
 sdl.web <at> gmail.com
Subject: Re: bug#17831: 24.4.50; bad default value for `Man-width'
Date: Wed, 25 Jun 2014 08:54:16 +0200

> None of this will ever work 100% reliably in the "M-x man" case,
> because while the command runs in the background, the user could
> change the window and frame configuration at will.

Indeed.

>> Alternatively, we could display the buffer first, look at what size we
>> get, fill the buffer, and possibly resize the window afterwards.  For
>> `with-temp-buffer-window' this means that we would have to fill the
>> buffer either via `temp-buffer-window-show-hook' or in QUIT-FUNCTION.
>
> But this will momentarily flash incorrect (e.g., empty) display,
> right?

While the buffer gets filled asynchronously?  Yes.  But it should work
in the synchronous case where the order would be (1) display the empty
buffer (2) fill it (3) resize the window accordingly.

> Not nice, IMO.

We could show some sort of placeholder here.

martin

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

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>, 
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 17831 <at> debbugs.gnu.org, sdl.web <at> gmail.com
Subject: Re: bug#17831: 24.4.50; bad default value for `Man-width'
Date: Wed, 25 Jun 2014 08:54:34 +0200

> Returning to the "M-x man" use case, I think the possibilities
> supported via the Man-width option is the best we can do.  So any
> users that are unhappy should be pointed to that option.

Agreed.  But then `display-buffer' should be passed the value specified
there together with a suitable function to make sure that the new window
doesn't get too small.

martin

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

From: Juri Linkov <juri <at> jurta.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: rudalics <at> gmx.at, Eli Zaretskii <eliz <at> gnu.org>, 17831 <at> debbugs.gnu.org,
 sdl.web <at> gmail.com
Subject: Re: bug#17831: 24.4.50; bad default value for `Man-width'
Date: Fri, 27 Jun 2014 02:49:55 +0300

>> This simple patch displays the buffer immediately,
>> but then slowly fills it with unformatted output
>> that doesn't look nice.
>
> Indeed, that's why I haven't made this change in Emacs years ago (when
> I made it in my local copy after getting too annoyed at the window-popup
> disruption).  The solution is obvious, tho: "Just" move the reformatting
> to the process-filter.

Using the same approach like processing escape sequences in grep/compilation
produces a nice result for M-x man: it displays the first formatted page
immediately and continues formatting the rest of the man page in background.
There are still small details to iron out but this is basically achieved
with the following patch.

There is one problem that I noticed on large man pages: formatting
small chunks by process-filter is little slower than formatting the
whole output like it currently does.  Could it be possible that
a slowdown is caused by `narrow-to-region'?  Then it's possible
to add two new arguments `min' and `max' to `Man-fontify-manpage'
to limit the processed region manually instead of using narrowing.

=== modified file 'lisp/man.el'
--- lisp/man.el	2014-05-09 07:02:00 +0000
+++ lisp/man.el	2014-06-27 00:49:22 +0000
@@ -1056,20 +1056,22 @@ (defun Man-getpage-in-background (topic)
       (require 'env)
       (message "Invoking %s %s in the background" manual-program man-args)
       (setq buffer (generate-new-buffer bufname))
+      (Man-notify-when-ready buffer)
       (with-current-buffer buffer
 	(setq buffer-undo-list t)
 	(setq Man-original-frame (selected-frame))
 	(setq Man-arguments man-args))
       (Man-start-calling
        (if (fboundp 'start-process)
-	    (set-process-sentinel
-	     (start-process manual-program buffer
-			    (if (memq system-type '(cygwin windows-nt))
-				shell-file-name
-			      "sh")
-			    shell-command-switch
-			    (format (Man-build-man-command) man-args))
-	     'Man-bgproc-sentinel)
+	   (let ((proc (start-process
+			manual-program buffer
+			(if (memq system-type '(cygwin windows-nt))
+			    shell-file-name
+			  "sh")
+			shell-command-switch
+			(format (Man-build-man-command) man-args))))
+	     (set-process-sentinel proc 'Man-bgproc-sentinel)
+	     (set-process-filter proc 'Man-bgproc-filter))
 	  (let ((exit-status
 		 (call-process shell-file-name nil (list buffer nil) nil
 			       shell-command-switch
@@ -1312,6 +1317,33 @@ (defun Man-cleanup-manpage (&optional in
   (Man-softhyphen-to-minus)
   (message "%s man page cleaned up" Man-arguments))
 
+(defun Man-bgproc-filter (process string)
+  "Manpage background process filter.
+When manpage command is run asynchronously, PROCESS is the process
+object for the manpage command; when manpage command is run
+synchronously, PROCESS is the name of the buffer where the manpage
+command is run.  Second argument STRING is the entire string of output."
+  (save-excursion
+    (let ((Man-buffer (if (stringp process) (get-buffer process)
+			(process-buffer process))))
+      (if (null (buffer-name Man-buffer)) ;; deleted buffer
+	  (or (stringp process)
+	      (set-process-buffer process nil))
+
+	(with-current-buffer Man-buffer
+	  (let ((inhibit-read-only t)
+	        (beg (marker-position (process-mark process))))
+	    (goto-char beg)
+	    (insert string)
+	    (save-restriction
+	      (narrow-to-region
+	       (save-excursion (goto-char beg) (line-beginning-position))
+	       (point))
+	      (if Man-fontify-manpage-flag
+		  (Man-fontify-manpage)
+		(Man-cleanup-manpage)))
+	    (set-marker (process-mark process) (point-max))))))))
+
 (defun Man-bgproc-sentinel (process msg)
   "Manpage background process sentinel.
 When manpage command is run asynchronously, PROCESS is the process
@@ -1365,9 +1398,6 @@ (defun Man-bgproc-sentinel (process msg)
 		 ))
         (if delete-buff
             (kill-buffer Man-buffer)
-          (if Man-fontify-manpage-flag
-              (Man-fontify-manpage)
-            (Man-cleanup-manpage))
 
           (run-hooks 'Man-cooked-hook)
 	  (Man-mode)
@@ -1378,11 +1408,6 @@ (defun Man-bgproc-sentinel (process msg)
 		(user-error "Can't find the %s manpage"
                             (Man-page-from-arguments args)))
 	    (set-buffer-modified-p nil))))
-	;; Restore case-fold-search before calling
-	;; Man-notify-when-ready because it may switch buffers.
-
-	(if (not delete-buff)
-	    (Man-notify-when-ready Man-buffer))
 
 	(if err-mess
 	    (error "%s" err-mess))

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Juri Linkov <juri <at> jurta.org>
Cc: rudalics <at> gmx.at, Eli Zaretskii <eliz <at> gnu.org>, 17831 <at> debbugs.gnu.org,
 sdl.web <at> gmail.com
Subject: Re: bug#17831: 24.4.50; bad default value for `Man-width'
Date: Thu, 26 Jun 2014 22:16:45 -0400

> Using the same approach like processing escape sequences in grep/compilation
> produces a nice result for M-x man: it displays the first formatted page
> immediately and continues formatting the rest of the man page in background.
> There are still small details to iron out but this is basically achieved
> with the following patch.

Looks good.

> There is one problem that I noticed on large man pages: formatting
> small chunks by process-filter is little slower than formatting the
> whole output like it currently does.

That's expected.

> Could it be possible that a slowdown is caused by `narrow-to-region'?

`narrow-to-region' is cheap.  But doing it by chunks is necessarily
slower, because there is a non-negligible overhead "per chunk".
`narrow-to-region' is part of that overhead, but there are others much
more costly, such as going through redisplay (which may even sometimes
have to update some part of the display, such as the "nn%" thingy since
that depends on the total buffer size).


        Stefan

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

From: Juri Linkov <juri <at> jurta.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: rudalics <at> gmx.at, Eli Zaretskii <eliz <at> gnu.org>, 17831 <at> debbugs.gnu.org,
 sdl.web <at> gmail.com
Subject: Re: bug#17831: 24.4.50; bad default value for `Man-width'
Date: Sat, 28 Jun 2014 02:45:59 +0300

>> Could it be possible that a slowdown is caused by `narrow-to-region'?
>
> `narrow-to-region' is cheap.  But doing it by chunks is necessarily
> slower, because there is a non-negligible overhead "per chunk".
> `narrow-to-region' is part of that overhead, but there are others much
> more costly, such as going through redisplay (which may even sometimes
> have to update some part of the display, such as the "nn%" thingy since
> that depends on the total buffer size).

If it's not possible to increase the default chunk size to call
process-filter less often (e.g. now for `M-x man RET bash' it's called
90 times), then some users might want to disable this using a new option
like `Man-sync'.  OTOH, since most of man pages are much smaller,
maybe this is not a problem.

But still the users need an indication that the formatting
is not finished.  grep/compilation and vc display a string
like "waiting..." or "compiling..." in the mode-line, so
man.el could display in the mode-line "formatting..."

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Juri Linkov <juri <at> jurta.org>
Cc: rudalics <at> gmx.at, Eli Zaretskii <eliz <at> gnu.org>, 17831 <at> debbugs.gnu.org,
 sdl.web <at> gmail.com
Subject: Re: bug#17831: 24.4.50; bad default value for `Man-width'
Date: Fri, 27 Jun 2014 21:30:50 -0400

> If it's not possible to increase the default chunk size to call
> process-filter less often (e.g. now for `M-x man RET bash' it's called
> 90 times), then some users might want to disable this using a new option
> like `Man-sync'.  OTOH, since most of man pages are much smaller,
> maybe this is not a problem.

I wouldn't worry 'bout it for now.  And this is not a problem specific
to M-x man.

> But still the users need an indication that the formatting
> is not finished.  grep/compilation and vc display a string
> like "waiting..." or "compiling..." in the mode-line, so
> man.el could display in the mode-line "formatting..."

Sound fine,


        Stefan

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

From: Juri Linkov <juri <at> jurta.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: rudalics <at> gmx.at, Eli Zaretskii <eliz <at> gnu.org>, 17831 <at> debbugs.gnu.org,
 sdl.web <at> gmail.com
Subject: Re: bug#17831: 24.4.50; bad default value for `Man-width'
Date: Mon, 30 Jun 2014 02:42:28 +0300

>> But still the users need an indication that the formatting
>> is not finished.  grep/compilation and vc display a string
>> like "waiting..." or "compiling..." in the mode-line, so
>> man.el could display in the mode-line "formatting..."
>
> Sound fine,

After testing I see no problems with this patch:

=== modified file 'lisp/man.el'
--- lisp/man.el	2014-05-09 07:02:00 +0000
+++ lisp/man.el	2014-06-29 23:37:38 +0000
@@ -1056,21 +1056,28 @@ (defun Man-getpage-in-background (topic)
       (require 'env)
       (message "Invoking %s %s in the background" manual-program man-args)
       (setq buffer (generate-new-buffer bufname))
+      (Man-notify-when-ready buffer)
       (with-current-buffer buffer
 	(setq buffer-undo-list t)
 	(setq Man-original-frame (selected-frame))
-	(setq Man-arguments man-args))
+	(setq Man-arguments man-args)
+	(Man-mode)
+	(setq mode-line-process
+	      (concat " " (propertize "[formatting...]"
+				      'face 'mode-line-emphasis))))
       (Man-start-calling
        (if (fboundp 'start-process)
-	    (set-process-sentinel
-	     (start-process manual-program buffer
+	   (let ((proc (start-process
+			manual-program buffer
 			    (if (memq system-type '(cygwin windows-nt))
 				shell-file-name
 			      "sh")
 			    shell-command-switch
-			    (format (Man-build-man-command) man-args))
-	     'Man-bgproc-sentinel)
-	  (let ((exit-status
+			(format (Man-build-man-command) man-args))))
+	     (set-process-sentinel proc 'Man-bgproc-sentinel)
+	     (set-process-filter proc 'Man-bgproc-filter))
+	 (let* ((inhibit-read-only t)
+		(exit-status
 		 (call-process shell-file-name nil (list buffer nil) nil
 			       shell-command-switch
 			       (format (Man-build-man-command) man-args)))
@@ -1082,6 +1089,10 @@ (defun Man-getpage-in-background (topic)
 			   (format "exited abnormally with code %d"
 				   exit-status)))
 		(setq msg exit-status))
+	   (with-current-buffer buffer
+	     (if Man-fontify-manpage-flag
+		 (Man-fontify-manpage)
+	       (Man-cleanup-manpage)))
 	    (Man-bgproc-sentinel bufname msg)))))
       buffer))
 
@@ -1168,7 +1179,6 @@ (defun Man-fontify-manpage ()
   "Convert overstriking and underlining to the correct fonts.
 Same for the ANSI bold and normal escape sequences."
   (interactive)
-  (message "Please wait: formatting the %s man page..." Man-arguments)
   (goto-char (point-min))
   ;; Fontify ANSI escapes.
   (let ((ansi-color-apply-face-function
@@ -1183,7 +1193,7 @@ (defun Man-fontify-manpage ()
 	;; Multibyte characters exist.
 	(progn
 	  (goto-char (point-min))
-	  (while (search-forward "__\b\b" nil t)
+	  (while (and (search-forward "__\b\b" nil t) (not (eobp)))
 	    (backward-delete-char 4)
 	    (put-text-property (point) (1+ (point)) 'face 'Man-underline))
 	  (goto-char (point-min))
@@ -1191,7 +1201,7 @@ (defun Man-fontify-manpage ()
 	    (backward-delete-char 4)
 	    (put-text-property (1- (point)) (point) 'face 'Man-underline))))
     (goto-char (point-min))
-    (while (search-forward "_\b" nil t)
+    (while (and (search-forward "_\b" nil t) (not (eobp)))
       (backward-delete-char 2)
       (put-text-property (point) (1+ (point)) 'face 'Man-underline))
     (goto-char (point-min))
@@ -1223,8 +1233,7 @@ (defun Man-fontify-manpage ()
     (while (re-search-forward Man-heading-regexp nil t)
       (put-text-property (match-beginning 0)
 			 (match-end 0)
-			 'face 'Man-overstrike)))
-  (message "%s man page formatted" (Man-page-from-arguments Man-arguments)))
+			 'face 'Man-overstrike))))
 
 (defun Man-highlight-references (&optional xref-man-type)
   "Highlight the references on mouse-over.
@@ -1286,8 +1295,6 @@ (defun Man-cleanup-manpage (&optional in
 but when called interactively, do those jobs even if the sed
 script would have done them."
   (interactive "p")
-  (message "Please wait: cleaning up the %s man page..."
-	   Man-arguments)
   (if (or interactive (not Man-sed-script))
       (progn
 	(goto-char (point-min))
@@ -1309,8 +1316,36 @@ (defun Man-cleanup-manpage (&optional in
   ;; their preceding chars (but don't put Man-overstrike).  (Bug#5566)
   (goto-char (point-min))
   (while (re-search-forward ".\b" nil t) (backward-delete-char 2))
-  (Man-softhyphen-to-minus)
-  (message "%s man page cleaned up" Man-arguments))
+  (Man-softhyphen-to-minus))
+
+(defun Man-bgproc-filter (process string)
+  "Manpage background process filter.
+When manpage command is run asynchronously, PROCESS is the process
+object for the manpage command; when manpage command is run
+synchronously, PROCESS is the name of the buffer where the manpage
+command is run.  Second argument STRING is the entire string of output."
+  (save-excursion
+    (let ((Man-buffer (process-buffer process)))
+      (if (null (buffer-name Man-buffer)) ;; deleted buffer
+	  (set-process-buffer process nil)
+
+	(with-current-buffer Man-buffer
+	  (let ((inhibit-read-only t)
+	        (beg (marker-position (process-mark process))))
+	    (save-excursion
+	      (goto-char beg)
+	      (insert string)
+	      (save-restriction
+		(narrow-to-region
+		 (save-excursion
+		   (goto-char beg)
+		   (line-beginning-position))
+		 (point))
+		(if Man-fontify-manpage-flag
+		    (Man-fontify-manpage)
+		  (Man-cleanup-manpage)))
+	      (set-marker (process-mark process) (point-max)))))))))
 
 (defun Man-bgproc-sentinel (process msg)
   "Manpage background process sentinel.
@@ -1329,6 +1364,7 @@ (defun Man-bgproc-sentinel (process msg)
 	    (set-process-buffer process nil))
 
       (with-current-buffer Man-buffer
+	(save-excursion
 	(let ((case-fold-search nil))
 	  (goto-char (point-min))
 	  (cond ((or (looking-at "No \\(manual \\)*entry for")
@@ -1364,28 +1400,34 @@ (defun Man-bgproc-sentinel (process msg)
 		       (insert (format "\nprocess %s" msg))))
 		 ))
         (if delete-buff
-            (kill-buffer Man-buffer)
-          (if Man-fontify-manpage-flag
-              (Man-fontify-manpage)
-            (Man-cleanup-manpage))
+		(if (get-buffer-window Man-buffer)
+		    (quit-window t (get-buffer-window Man-buffer))
+		  (kill-buffer Man-buffer))
 
           (run-hooks 'Man-cooked-hook)
-	  (Man-mode)
+
+	      (Man-build-page-list)
+	      (Man-strip-page-headers)
+	      (Man-unindent)
+	      (Man-goto-page 1 t)
 
 	  (if (not Man-page-list)
  	      (let ((args Man-arguments))
-		(kill-buffer (current-buffer))
-		(user-error "Can't find the %s manpage"
+		    (if (get-buffer-window (current-buffer))
+			(quit-window t (get-buffer-window (current-buffer)))
+		      (kill-buffer (current-buffer)))
+		    (message "Can't find the %s manpage"
                             (Man-page-from-arguments args)))
-	    (set-buffer-modified-p nil))))
-	;; Restore case-fold-search before calling
-	;; Man-notify-when-ready because it may switch buffers.
 
-	(if (not delete-buff)
-	    (Man-notify-when-ready Man-buffer))
+		(if Man-fontify-manpage-flag
+		    (message "%s man page formatted" (Man-page-from-arguments Man-arguments))
+		  (message "%s man page cleaned up" Man-arguments))
+		(unless (and (processp process) (not (eq (process-status process) 'exit)))
+		  (setq mode-line-process nil))
+		(set-buffer-modified-p nil)))))
 
 	(if err-mess
-	    (error "%s" err-mess))
+	    (message "%s" err-mess))
 	))))
 
 (defun Man-page-from-arguments (args)
@@ -1458,11 +1500,7 @@ (define-derived-mode Man-mode fundamenta
   (set (make-local-variable 'outline-regexp) Man-heading-regexp)
   (set (make-local-variable 'outline-level) (lambda () 1))
   (set (make-local-variable 'bookmark-make-record-function)
-       'Man-bookmark-make-record)
-  (Man-build-page-list)
-  (Man-strip-page-headers)
-  (Man-unindent)
-  (Man-goto-page 1 t))
+       'Man-bookmark-make-record))
 
 (defsubst Man-build-section-alist ()
   "Build the list of manpage sections."

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Juri Linkov <juri <at> jurta.org>
Cc: rudalics <at> gmx.at, Eli Zaretskii <eliz <at> gnu.org>, 17831 <at> debbugs.gnu.org,
 sdl.web <at> gmail.com
Subject: Re: bug#17831: 24.4.50; bad default value for `Man-width'
Date: Sun, 29 Jun 2014 23:29:23 -0400

>> Sound fine,
> After testing I see no problems with this patch:

Great, thanks,


        Stefan

Previous Next

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