all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: rms@gnu.org
Cc: emacs-devel@gnu.org
Subject: Re: redisplay-dont-pause
Date: Thu, 15 Sep 2011 00:59:17 -0400	[thread overview]
Message-ID: <E1R442f-0008Dx-9R@fencepost.gnu.org> (raw)
In-Reply-To: <E1R43Iu-0003Wh-BO@fencepost.gnu.org> (message from Richard Stallman on Thu, 15 Sep 2011 00:12:00 -0400)

> 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.



  reply	other threads:[~2011-09-15  4:59 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-14 15:36 redisplay-dont-pause Eli Zaretskii
2011-09-14 15:38 ` redisplay-dont-pause Juanma Barranquero
2011-09-14 16:12 ` redisplay-dont-pause Leo
2011-09-14 17:09   ` redisplay-dont-pause Eli Zaretskii
2011-09-15  4:12     ` redisplay-dont-pause Richard Stallman
2011-09-15  5:24       ` redisplay-dont-pause Eli Zaretskii
2011-09-15  2:10 ` redisplay-dont-pause Christoph Scholtes
2011-09-15  3:03   ` redisplay-dont-pause Eli Zaretskii
2011-09-15  4:12 ` redisplay-dont-pause Richard Stallman
2011-09-15  4:59   ` Eli Zaretskii [this message]
2011-09-15 22:02     ` redisplay-dont-pause Richard Stallman
2011-09-16  7:23       ` redisplay-dont-pause Eli Zaretskii
2011-09-16 17:29         ` redisplay-dont-pause Richard Stallman
2011-09-16 17:45           ` redisplay-dont-pause Eli Zaretskii
2011-09-17  0:36             ` redisplay-dont-pause Richard Stallman
2011-09-17  8:13               ` redisplay-dont-pause Eli Zaretskii
2011-09-17 19:43                 ` redisplay-dont-pause Chong Yidong
2011-09-24 14:39                   ` redisplay-dont-pause Eli Zaretskii
2011-09-17 21:30                 ` redisplay-dont-pause Stefan Monnier
2011-09-18 11:07                   ` redisplay-dont-pause Juanma Barranquero

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=E1R442f-0008Dx-9R@fencepost.gnu.org \
    --to=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=rms@gnu.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.