whm@arizona.UUCP (Bill Mitchell) (02/11/85)
I've just started using the T2.00 version from Unipress and I've noticed
something that worked in #264 that doesn't seem to be present in the
T2.00 version.
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.
Is anyone from Unipress familiar with this behavior?
I'm not happy.
Bill Mitchell
whm.arizona@csnet-relay
{ihnp4,noao,mcnc,utah-cs}!arizona!whmwhm@arizona.UUCP (Bill Mitchell) (02/11/85)
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