GNU bug report logs - #13623
24.3.50; Redisplay issue with transient-mark-mode

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Antipov <dmantipov <at> yandex.ru>
Cc: wence <at> gmx.li, 13623 <at> debbugs.gnu.org, monnier <at> IRO.UMontreal.CA
Subject: bug#13623: 24.3.50; Redisplay issue with transient-mark-mode
Date: Wed, 06 Feb 2013 20:04:17 +0200

> Date: Wed, 06 Feb 2013 19:14:43 +0400
> From: Dmitry Antipov <dmantipov <at> yandex.ru>
> CC: Eli Zaretskii <eliz <at> gnu.org>, wence <at> gmx.li, 13623 <at> debbugs.gnu.org
> 
> On the other side, I suspect that the most of users
> are either 1) uses single-frame configuration or 2) uses reasonably modern
> hardware where the complete redisplay (all frames) is faster than the period
> between two keystrokes and so doesn't affect an editing experience.

I doubt many users use only one frame.  I certainly don't, although my
usage patterns are pretty conservative, nowhere near Stefan's.

As for full redisplay: please remember that there are 2 aspects to
that: (1) on the xdisp.c level, which is device independent, and
(2) on the device-dependent xterm.c/w32term.c/nsterm.m etc. level.
Even if on the xdisp.c level we do a complete redisplay of a window,
update_frame and its subroutines compare the desired and the current
display and only redraw the lines that are different.  Therefore, you
could do a complete redisplay on xdisp.c level, and then redraw very
little or even nothing at all, even if your video hardware is 10 years
old.

I'm saying that because due to this 2-level optimization, the hardware
speed is rarely seen in Emacs.

Previous Next

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