trost@reed.bitnet (Bill Trost,Box 607,ext 571,497) (01/15/90)
In article <LVN6S^@rpi.edu>, tale@cs.rpi.edu (David C Lawrence) writes: [ a whole lot of neat stuff, including: ] >That is, you could say, "Crap! 707 articles in comp.windows.x! I >think I'll edit foo.c while it is retrieving them." So you go off and >start editing foo.c... Hmm, not quite what I had in mind. My intent was more along the lines of having gnus read in the first few articles, handing them to the user, and then continue reading in the rest asycronously. I tend to dedicate a block of time to reading news, and going off and "finding something else to do" isn't in my programming. Having the list of articles grow as I sit there and read it, on the other hand, would be very pleasant. This approach also reduces the problem with emacs being slowed down by all the incoming nntp's (or whatever you want to call the equivalent under nnspool). You're mostly just sitting and reading anyhow, so the slowdown will only be apparent on paging and such. >> (while (not (input-pending-p)) >> (gnus-fetch-next-header)) .... >In the example above, say input is pending. So you exit your loop and >have it execute the command it was just given. How would that be done >very cleanly, especially so that the loop was re-entered after the >command was executed? You don't. When trying to do something like, say, replying to a news, the background activity would probably be rather intrusive. Instead, you have background reading *started* at appropriate moments, like after a page-down or a next-article --- times when you know that the user is going to be sitting there and reading. >Suggestions are welcome, preferably public on this list/group as I >would appreciate open discussion on what people think is The Right >Thing. It seems that such discussion often has the potential to flush >out ideas that wouldn't otherwise be heard. Yeah, what he said. -- trost@reed.bitnet, but probably trost%reed@tektronix.tek.com