🚀 go-pugleaf

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"))