redisplay-dont-pause

redisplay-dont-pause

[Eli Zaretskii]

Any objections to change the default value of this option to t?  The
reasons for its nil value are long gone, AFAIK, and it definitely
improves user experience when redisplay needs to work hard.

Re: redisplay-dont-pause

[Juanma Barranquero]

On Wed, Sep 14, 2011 at 17:36, Eli Zaretskii <eliz@gnu.org> wrote:

> and it definitely
> improves user experience when redisplay needs to work hard.

+1

    Juanma

Re: redisplay-dont-pause

[Leo]

On 2011-09-14 23:36 +0800, Eli Zaretskii wrote:
> Any objections to change the default value of this option to t?  The
> reasons for its nil value are long gone, AFAIK, and it definitely
> improves user experience when redisplay needs to work hard.

What was the reason for it to be nil? Thanks.

Leo

Re: redisplay-dont-pause

[Eli Zaretskii]

> From: Leo <sdl.web@gmail.com>
> Cc: emacs-devel@gnu.org
> Date: Thu, 15 Sep 2011 00:12:10 +0800
> 
> On 2011-09-14 23:36 +0800, Eli Zaretskii wrote:
> > Any objections to change the default value of this option to t?  The
> > reasons for its nil value are long gone, AFAIK, and it definitely
> > improves user experience when redisplay needs to work hard.
> 
> What was the reason for it to be nil? Thanks.

Long ago (I'm talking Emacs 21.1 days, like 2001), setting that option
would cause incomplete redisplay sometimes.

Re: redisplay-dont-pause

[Christoph Scholtes]

On 9/14/2011 9:36 AM, Eli Zaretskii wrote:
> Any objections to change the default value of this option to t?  The
> reasons for its nil value are long gone, AFAIK, and it definitely
> improves user experience when redisplay needs to work hard.

All the redraw/slowness issues I had scrolling through big files 
disappeared after setting this to t. What's the downside of doing this?

Re: redisplay-dont-pause

[Eli Zaretskii]

> Date: Wed, 14 Sep 2011 20:10:17 -0600
> From: Christoph Scholtes <cschol2112@googlemail.com>
> CC: emacs-devel@gnu.org
> 
> All the redraw/slowness issues I had scrolling through big files 
> disappeared after setting this to t. What's the downside of doing this?

None that I know of.  Theoretically, Emacs is slightly less responsive
to user input, because it doesn't stop redisplay when input is
available, but instead first finished the redisplay cycle completely.
But that's theory; in practice, the user experience is that Emacs is
perhaps even _more_ responsive, especially if the user command
involves significant redisplay, like scrolling.

Re: redisplay-dont-pause

[Richard Stallman]

    Any objections to change the default value of this option to t?  The
    reasons for its nil value are long gone, AFAIK, and it definitely
    improves user experience when redisplay needs to work hard.

How does setting it to t improve things?


-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

Re: redisplay-dont-pause

[Richard Stallman]

    Long ago (I'm talking Emacs 21.1 days, like 2001), setting that option
    would cause incomplete redisplay sometimes.

If that occurred, it was due to a bug.  I hope it is fixed now.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

Re: redisplay-dont-pause

[Eli Zaretskii]

> Date: Thu, 15 Sep 2011 00:12:00 -0400
> From: Richard Stallman <rms@gnu.org>
> CC: emacs-devel@gnu.org
> Reply-to: rms@gnu.org
> 
>     Any objections to change the default value of this option to t?  The
>     reasons for its nil value are long gone, AFAIK, and it definitely
>     improves user experience when redisplay needs to work hard.
> 
> How does setting it to t improve things?

When the value is nil, Emacs checks at several places during redisplay
whether some input is available, and if so, it aborts the redisplay
cycle to handle the incoming input.  That has the effect of forcing a
full redisplay on the next opportunity, for those frames that were not
completely redisplayed.  Here, "full" means that all display
optimizations are wholesale disabled for all windows on the frame.
E.g., even just moving the cursor or scrolling by one line will redraw
the entire window.

This adversely affects the user experience when you lean on some key,
like C-n or C-v, and Emacs gets input events at the keyboard
auto-repeat rate (which is generally quite high nowadays): frequently,
the display gets stuck because Emacs cannot keep up with the input and
completely stops displaying.

Setting the variable to t has 2 effects:

 . it lets Emacs use redisplay optimizations more often, which are a
   big win for commands that generally just move without changing the
   buffer, thus boosting Emacs's ability to process input faster;

 . it effectively slows down the keyboard auto-repeat rate (because
   events need to wait for the end of redisplay before they are
   processed), but only by a small factor, so the user experience is
   that Emacs does succeed to keep up.

Re: redisplay-dont-pause

[Eli Zaretskii]

> Date: Thu, 15 Sep 2011 00:12:05 -0400
> From: Richard Stallman <rms@gnu.org>
> CC: sdl.web@gmail.com, emacs-devel@gnu.org
> Reply-to: rms@gnu.org
> 
>     Long ago (I'm talking Emacs 21.1 days, like 2001), setting that option
>     would cause incomplete redisplay sometimes.
> 
> If that occurred, it was due to a bug.  I hope it is fixed now.

Some people (myself included) run with this option set to t all the
time, and no related problems were reported, AFAIK.  So I think any
bugs we might have had in the past are long gone.

Re: redisplay-dont-pause

[Richard Stallman]

    When the value is nil, Emacs checks at several places during redisplay
    whether some input is available, and if so, it aborts the redisplay
    cycle to handle the incoming input.  That has the effect of forcing a
    full redisplay on the next opportunity, for those frames that were not
    completely redisplayed.  Here, "full" means that all display
    optimizations are wholesale disabled for all windows on the frame.

That is strange.  I wonder why it does that?

In the old days, Emacs would update the display records for each line
that it output, so that the subsequent redisplay would know where it
was starting from.

Maybe this has to do with the variable height of lines, and overlap of lines.

    the display gets stuck because Emacs cannot keep up with the input and
    completely stops displaying.

Over any substantial period, if the commands come so fast that excuting
them leaves no time for redisplay, Emacs should not redisplay at all.
You might describe that by saying "the display gets stuck", but this
is what should happen.

     . it effectively slows down the keyboard auto-repeat rate (because
       events need to wait for the end of redisplay before they are
       processed), but only by a small factor, so the user experience is
       that Emacs does succeed to keep up.

I am lost here.  The keyboard determines its auto-repeat rate.
Emacs can't slow it down.  All it can do is skip redisplays so
as to cope with the commands at the rate they are generated.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

Re: redisplay-dont-pause

[Eli Zaretskii]

> Date: Thu, 15 Sep 2011 18:02:52 -0400
> From: Richard Stallman <rms@gnu.org>
> CC: emacs-devel@gnu.org
> 
>     When the value is nil, Emacs checks at several places during redisplay
>     whether some input is available, and if so, it aborts the redisplay
>     cycle to handle the incoming input.  That has the effect of forcing a
>     full redisplay on the next opportunity, for those frames that were not
>     completely redisplayed.  Here, "full" means that all display
>     optimizations are wholesale disabled for all windows on the frame.
> 
> That is strange.  I wonder why it does that?

Because the optimizations rely on the display being up to date, which
cannot be assured if redisplay was aborted half way through.  The
current display engine is very conservative about that, and any of the
indications that the display might not be entirely accurate disable
most if not all of the optimizations.

> In the old days, Emacs would update the display records for each line
> that it output, so that the subsequent redisplay would know where it
> was starting from.

There are no such fine-grained display records in the current display
engine, AFAIK.  Perhaps that's something that was planned, but never
implemented.  Or maybe implementing it is very hard with the current
display features, I really cannot say.

> Over any substantial period, if the commands come so fast that excuting
> them leaves no time for redisplay, Emacs should not redisplay at all.
> You might describe that by saying "the display gets stuck", but this
> is what should happen.

Right.  But the net effect on the user experience is negative.

>      . it effectively slows down the keyboard auto-repeat rate (because
>        events need to wait for the end of redisplay before they are
>        processed), but only by a small factor, so the user experience is
>        that Emacs does succeed to keep up.
> 
> I am lost here.  The keyboard determines its auto-repeat rate.
> Emacs can't slow it down.  All it can do is skip redisplays so
> as to cope with the commands at the rate they are generated.

That's why I said "effectively".  The keyboard of course works at its
nominal speed, but Emacs lets input events wait in its queue for some
short time, thus the rate of event processing is slightly lower than
what the keyboard produces.  It's hard to time such fast sequences
with the existing facilities, but I'm quite sure that letting
redisplay optimizations do their best is on balance a win, and only
some input events need to wait in the queue before they are processed.
IOW, setting this variable non-nil actually helps Emacs to keep up
with high-rate input, because the cost of a full redisplay is so much
higher.

Re: redisplay-dont-pause

[Richard Stallman]

    Because the optimizations rely on the display being up to date, which
    cannot be assured if redisplay was aborted half way through.

There is no reason in principle that it can't be assured.
The display code I wrote assured the integrity of the records,
even when it stopped having updated only some of the lines.
And the multi-font display code in Emacs 19 did so too.

Maybe there is no need now to support pauses in redisplay.  I am not
arguing about that.  However, I would like to set the record straight
about this basic point.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

Re: redisplay-dont-pause

[Eli Zaretskii]

> Date: Fri, 16 Sep 2011 13:29:42 -0400
> From: Richard Stallman <rms@gnu.org>
> CC: emacs-devel@gnu.org
> 
>     Because the optimizations rely on the display being up to date, which
>     cannot be assured if redisplay was aborted half way through.
> 
> There is no reason in principle that it can't be assured.
> The display code I wrote assured the integrity of the records,
> even when it stopped having updated only some of the lines.
> And the multi-font display code in Emacs 19 did so too.

Perhaps if you describe the design of how the old display engine kept
records about up-to-dateness of display portions, we could see if the
same design principles can be used with the current display engine,
and maybe implement such a feature.

Re: redisplay-dont-pause

[Richard Stallman]

    Perhaps if you describe the design of how the old display engine kept
    records about up-to-dateness of display portions, we could see if the
    same design principles can be used with the current display engine,
    and maybe implement such a feature.

I could if someone wants to work on this, but is it worth doing?
If we have no need to support pausing the display any more,
it wouldn't be worth spending time to implement this now.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

Re: redisplay-dont-pause

[Eli Zaretskii]

> Date: Fri, 16 Sep 2011 20:36:30 -0400
> From: Richard Stallman <rms@gnu.org>
> CC: emacs-devel@gnu.org
> 
>     Perhaps if you describe the design of how the old display engine kept
>     records about up-to-dateness of display portions, we could see if the
>     same design principles can be used with the current display engine,
>     and maybe implement such a feature.
> 
> I could if someone wants to work on this, but is it worth doing?
> If we have no need to support pausing the display any more,
> it wouldn't be worth spending time to implement this now.

I agree, so let's wait for the decision by Stefan and Chong whether to
change the default of this variable.

Re: redisplay-dont-pause

[Chong Yidong]

Eli Zaretskii <eliz@gnu.org> writes:

> I agree, so let's wait for the decision by Stefan and Chong whether to
> change the default of this variable.

I think this change is fine; please go ahead.  The Lisp manual would
need updating too.

Re: redisplay-dont-pause

[Stefan Monnier]

>> I could if someone wants to work on this, but is it worth doing?
>> If we have no need to support pausing the display any more,
>> it wouldn't be worth spending time to implement this now.
> I agree, so let's wait for the decision by Stefan and Chong whether to
> change the default of this variable.

I don't have any strong opinion on this.  So if you want to change it,
I think it's OK.  Whenever I tried to play with it, it never seemed to
make much difference either way for me.


        Stefan

Re: redisplay-dont-pause

[Juanma Barranquero]

On Sat, Sep 17, 2011 at 23:30, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> Whenever I tried to play with it, it never seemed to
> make much difference either way for me.

With line-by-line scrolling the effect is quite noticeable, at least on Windows.

    Juanma

Re: redisplay-dont-pause

[Eli Zaretskii]

> From: Chong Yidong <cyd@stupidchicken.com>
> Cc: rms@gnu.org, emacs-devel@gnu.org
> Date: Sat, 17 Sep 2011 15:43:02 -0400
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I agree, so let's wait for the decision by Stefan and Chong whether to
> > change the default of this variable.
> 
> I think this change is fine; please go ahead.  The Lisp manual would
> need updating too.

Done.