Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site arizona.UUCP Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!ihnp4!arizona!whm From: whm@arizona.UUCP (Bill Mitchell) Newsgroups: net.emacs Subject: Re: "interruptable" screen updates Message-ID: <21483@arizona.UUCP> Date: Mon, 11-Feb-85 03:43:30 EST Article-I.D.: arizona.21483 Posted: Mon Feb 11 03:43:30 1985 Date-Received: Tue, 12-Feb-85 04:49:30 EST References: <21482@arizona.UUCP> Distribution: net Organization: Dept of CS, U of Arizona, Tucson Lines: 37 A few minutes ago I wrote: > > Namely, in #264, if I initiated an action that would take some non-trivial > amount of real-time, such as a partial redraw of the screen at 1200 baud, > and I then hit another key that caused another screen update, the first > update would soon stop and the latter screen update would be performed. In > the new version, it seems that the first update is completed before > the second one is started. When using emacs-rnews, this often doubles or > triples the real-time required to move through a number of non-interesting > articles. I suddenly couldn't bear emacs-rnews with this new behavior so I had to get to the bottom of the problem before I could continue reading my news. It turns out that the new "gentty" system is the culprit. There seems to be a macro OUTCHRPEND(fd) which provides the number of output characters pending on file descriptor fd. In gentty.h, OUTCHRPEND is defined to be 0 for all flavors of terminal drivers and has associated comments such as "don't know how to do this yet". Nonetheless, OUTCHRPEND is only used in one place in display.c and if you replace the expression: OUTCHRPEND(fileno(stdin)) with the #264 code, which reads: (stdout->_ptr - stdout->_base) things work like they used to. My T2.00 tape is about a month old so it wouldn't be surprising if Unipress has corrected this bogon in the meantime. Back to the reading the news, Bill Mitchell whm.arizona@csnet-relay {ihnp4,noao,mcnc,utah-cs}!arizona!whm