Title XEmacs and toolbars over a slow link
Type defect Module core code 21.5
Severity inconvenience Platform unix, xt
Keywords redisplay Nosy List
These controls should only be changed by committers and tracker administrators.
Status chatting   Reason
Superseder   Submitted 2008-01-18.22:08:41
Priority normal   Assigned To

Created on 2008-01-19.04:58:07 by stephen, last changed 2008-01-19.10:15:03 by admin.

msg430 [hidden] ([hidden]) Date: 2008-01-19.10:15:03
See also issue240.

In the email thread, turning off toolbars was mentioned as a
reasonable workaround.
msg136 [hidden] ([hidden]) Date: 2008-01-19.04:58:07
  Message-ID: <>
Jerry James writes:

 > Yes, even when the toolbar doesn't change because the new buffer is in
 > the same mode as the old buffer, it redraws itself.  This is
 > especially annoying when using Gnus.  I agree that it's annoying, but
 > I've never gone digging through the code to find out why it happens.

I have.  Basically, Andy added the widgets in a style that seems to
assume that anything can draw anywhere, and there are no widgets that
know how to maintain themselves.  (Maybe you need to do this in MS
Windows and Carbon?)  So everything in the lwlib and redisplay code
now is infested with a million ad hoc dirty flags, and redisplay tries
to manage widget redraws by hand (unmapping the subwindows instead of
letting X11 optimize calls for obscured parts or setting an
appropriate clip region).

My guess is that some of these then set dirty flags ....

XEmacs-Beta mailing list
Date User Action Args
2008-01-19 10:17:13adminlinkissue240 superseder
2008-01-19 10:15:03adminsetstatus: new -> chatting
priority: normal
severity: inconvenience
keyword: + redisplay
platform: + unix, xt
type: defect
messages: + msg430
module: + core code 21.5
2008-01-19 04:58:07stephencreate