Path: utzoo!telly!attcan!uunet!crdgw1!rpi!tale From: tale@cs.rpi.edu (David C Lawrence) Newsgroups: gnu.emacs.gnus Subject: Re: Is anyone maintaining GNUS these days? Message-ID: Date: 12 Jan 90 07:29:54 GMT References: <%&LY9@rpi.edu> <13853@reed.UUCP> Organization: Rensselaer Polytechnic Institute, Troy NY Lines: 71 In article <13853@reed.UUCP> trost@reed.bitnet (Bill Trost) writes: > Something I would like to see that would nicely *replace* the large > newsgroup stuff would be background acquisition of news articles. I > imagine some loop somewhere (called after "n" and " " and "." and > other common news-reading keys) like > (while (not (input-pending-p)) > (gnus-fetch-next-header)) This seems like a good topic to discuss in this forum now. I don't know the best solution, but I don't think this rough idea is feasible. Then again, it could just be my own short-sightedness because of the way I read news compared to the way other people do. I recognise these differences though and am open for suggestions. These differences are part of what make me not like nn very much even though other people love it. A few months ago someone asked me if I/he/we (I don't remember) could make GNUS retrieve newsgroups in the background as an asynchronous procedure. While my initial reaction was, "Yeah! Should work on that ..." I soon realised that it was not such a hot idea because GNUS takes over again as soon as its headers are retrieved. 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 and as soon as those articles are all retrieved GNUS kicks in again and takes over your environment, possibly grabbing keystrokes that you just intended to be part of a printf call. There seem to be a couple of different possibilities here. It could just check to see whether you are in the *Newsgroup* or *Subject* buffer when it has all of the information it wants. If not, then it would just politely put a message in the echo area, with a ding, telling you that your *Subject* buffer is ready. But then how should you get to it? People like me who have gnus-use-full-window non-nil and gnus-window-configuration set to mimic pre-3.12 behaviour would have no problem just doing a switch-to-buffer and continuing from there. But what about the people who want a special window configuration? Another thing to bear in mind is that while GNUS is retrieving its articles via NNTP it would a) be very easy to do asynchronously but b) make working extremely slow as all of that data was being shoved through the filter every second anyway. When using local spool (including NFS/RFS/FooFS) then you could make it so the speed was less of a problem but making it asynchronous would be a little harder. 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 could read keys and process them as applicable but at the moment there seems to be no nice way of modifying the context that the command might want to modify yet keeping everything else as it was. I say "at the moment" because there might indeed be an elegant way to accomplish this that is just not firing on my tired synapses right now. 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. It also might incite someone like Roland (who has also hacked GNUS) to do it sooner than I will likely be able to get to it. > David, how long do you think it would take you to pull off something > like this? Given my current work load and a somewhat unclear direction to proceed in, probably not before the end of the month. I don't know beyond that. Dave -- (setq mail '("tale@cs.rpi.edu" "tale@ai.mit.edu" "tale@rpitsmts.bitnet"))