Gnus development mailing list
 help / color / mirror / Atom feed
* Operating in multiple summary buffers simultaneously?
@ 2000-04-16 18:55 Lloyd Zusman
  2000-04-16 19:55 ` Kai Großjohann
  0 siblings, 1 reply; 2+ messages in thread
From: Lloyd Zusman @ 2000-04-16 18:55 UTC (permalink / raw)


I'm using the latest Gnus from CVS under XEmacs 21.1.9.

I'm wondering if I can work in multiple summary buffers
simultaneously.  Here's what I want to do (please bear with me as I
explain this, as it's a somewhat complicated set-up):

I have developed a procedure whereby a list of rather large documents,
programs, images, etc. are kept on a server that I access remotely
from my dial-up PPP connection at home.  On the server I have a
procedure that automatically makes small newsgroup articles containing
summaries of these larger objects, and periodically these summary
articles are downloaded to my local machine into a special newsgroup.
I read this newsgroup at home using Gnus.

I've written the appropriate elisp functions that let me go through
this newsgroup and optionally mark these objects for either download
or deletion.  Then, I invoke another procedure which, via an
asynchronous `efs' procedure, performs these downloads and deletions.
After each object has been deleted or downloaded, an appropriate `efs'
callback marks the appropriate article in my newsgroup accordingly.

This is where I'm having problems.  As long as the summary buffer for
special newsgroup is the buffer that I'm "in" within my Gnus session,
everything works fine.  But if I interactively change buffers during
this asynchronous `efs' procedure in order to read other news or
whatever, the context gets lost when it comes time for my callback to
mark the article that it's been working on.

If it were possible for me to set up some sort of "buffer context" for
my `efs' callback which would force it to work in the appropriate Gnus
buffer no matter what, then this would be fine.  But there are some
pitfalls here.  I already am doing making use of `save-excursion',
`set-buffer', etc. within my `efs' callback, but this doesn't seem to
be enough, because there seems to be some global state that gets
changed when I interactively quit from this particular summary buffer
and switch to another one.

I'm not sure of all the internal Gnus details of what's going on here.
Perhaps what I want to do would be very easy if I just made use of
certain functions that I'm unfamiliar with ... ???

At any rate, does anyone know of a way I can seamlessly have
asynchronous operations being performed in a summary buffer for which
I am currently not "in" as part of my interactive Gnus session?

Thanks in advance.

-- 
 Lloyd Zusman
 ljz@asfast.com



^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Operating in multiple summary buffers simultaneously?
  2000-04-16 18:55 Operating in multiple summary buffers simultaneously? Lloyd Zusman
@ 2000-04-16 19:55 ` Kai Großjohann
  0 siblings, 0 replies; 2+ messages in thread
From: Kai Großjohann @ 2000-04-16 19:55 UTC (permalink / raw)
  Cc: ding

If I understand you correctly, your procedure does two things:

(1) Download or delete some objects, and
(2) tell Gnus about it.

And it appears that the problem is with step (2).

One possible way of attach would be to sidestep the whole issue and to
let your procedure write stuff into a file which is then read by Gnus
at specified points so that the Gnus state is updated.

Maybe you could write stuff into the dribble buffer (file)?

kai
-- 
The birch trees fly way too low these days.



^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2000-04-16 19:55 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-04-16 18:55 Operating in multiple summary buffers simultaneously? Lloyd Zusman
2000-04-16 19:55 ` Kai Großjohann

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).