pgnus commandeers emacs to check mail

pgnus commandeers emacs to check mail

[Bill White]

Sounds like a newspaper headline.

This is about my only continuing gripe with gnus:

When pgnus checks for new mail/news, I can't do anything in that
invocation of emacs until pgnus finishes. Keyboard input is
accumulated until then. When our news server is slow or if there's a
boatload of email to download, emacs can be useless for quite a while.

This happens with 'g' in the *Group* buffer, and also with the
automatic "check mail/news and update *Group* buffer" function in
.gnus:

; Posted to ding or gnu.emacs.gnus long ago...
; The catch with gnus-demon-scanmail seems to be that the Group buffer
; doesn't get updated when the mail is fetched (so nothing actually
; appears to happen). I do this instead:

(gnus-demon-add-handler (lambda () (gnus-group-get-new-news t)) 10 nil)

Is there a way to make mail/news checking a completely unobtrusive
thing? 

Pterodactyl Gnus v0.95, GNU Emacs 20.4.1 (i586-pc-linux-gnu, X
toolkit) of Fri Jul 16 1999 on g.wolfram.com

This was also seen in Emacs 20.3 and all the 20.4 prereleases.

Thanks -

bw
-- 
Bill White . billw@wolfram.com . http://members.wri.com/billw

Re: pgnus commandeers emacs to check mail

[Kai Großjohann]

Bill White <billw@wolfram.com> writes:

> Is there a way to make mail/news checking a completely unobtrusive
> thing? 

Hm.  Since Emacs is not multithreaded (yet), you must delegate the
process of putting mails into folders to some other program.  But
Emacs thinks it owns the ~/Mail directory (horrible things will happen
if you dare write into ~/Mail!), which makes this kinda difficult.

One way to achieve this is to use nnimap and to read mail via IMAP.  I
have configured things such that the Cyrus `deliver' programm
automatically puts mail into the right folder.  That means that, when
you hit `g', Gnus quickly scans all nnimap groups to see whether there
is new mail, and this time does not depend on the amount of new mail,
only on the number of groups.

Another way to possibly achieve it is to write into ~/Mail anyway if
you know exactly what you're doing.  I think you won't have much luck
unless you use the nnmh backend, and that is so slow compared with
nnml that this won't help you either.  And for nnfolder groups, Gnus
has the files in memory.

Btw, wouldn't it be possible to tell Gnus to have a look at the
overview files to see if the in-memory copy is still up to date before
changing anything in them?  This would kind of make it possible to use
nnml, if it weren't for race conditions.  Could some locking mechanism
be added?

kai
-- 
Life is hard and then you die.

Re: pgnus commandeers emacs to check mail

[Greg Stark]

Kai Großjohann <Kai.Grossjohann@CS.Uni-Dortmund.DE> writes:

> Bill White <billw@wolfram.com> writes:
> 
> > Is there a way to make mail/news checking a completely unobtrusive
> > thing? 
> 
> Hm.  Since Emacs is not multithreaded (yet), you must delegate the

No, I described how to do an asynchronous interface between Gnus and the
backends back during September Gnus, I made another push for it during Red
Gnus too. I don't remember if I repeated it again for Quassia or if I had
given up by then.

It is absolutely possible to impelement an asynchronous interface for Gnus and
it would be the single most effective usability improvement that coudl be made
to Gnus. (imho of course).

If you don't believe this is possible search the mail archives for my
explanation; I don't have time to type up the explanation again. If you're
still not convinced trust me, I have an asynchronous backend here right now! I
regularly use emacs while it's downloading headers from that backend.

Unfortunately because the interface to Gnus is inherently synchronous I'm
stuck using a kludge with recursive-edit's which doesn't scale to multiple
backends.

If we had a real asynchronous interface between Gnus and the backends, as I
described back in September Gnus then lots of backends could do what my
abckend does here and all coexist in the same emacs.

greg

Re: pgnus commandeers emacs to check mail

[Hrvoje Niksic]

Greg Stark <gsstark@mit.edu> writes:

> Unfortunately because the interface to Gnus is inherently
> synchronous I'm stuck using a kludge with recursive-edit's which
> doesn't scale to multiple backends.

Now all we need is a Schemer to chime in with "...but if Elisp
supported continuations, recursive-edits would work just fine for
multiple backends..." and thus win the second place in "I missed the
whole point awards."

(The first place goes to the multithreading dudes, of course.)

Re: pgnus commandeers emacs to check mail

[Michael Sperber [Mr. Preprocessor]]

>>>>> "Hrvoje" == Hrvoje Niksic <hniksic@srce.hr> writes:

Hrvoje> Greg Stark <gsstark@mit.edu> writes:

>> Unfortunately because the interface to Gnus is inherently
>> synchronous I'm stuck using a kludge with recursive-edit's which
>> doesn't scale to multiple backends.

Hrvoje> Now all we need is a Schemer to chime in with "...but if Elisp
Hrvoje> supported continuations, recursive-edits would work just fine for
Hrvoje> multiple backends..." and thus win the second place in "I missed the
Hrvoje> whole point awards."

I wonder who you might be talking about? :-)

-- 
Cheers =8-} Chipsy
Friede, Völkerverständigung und überhaupt blabla

Re: pgnus commandeers emacs to check mail

[Stainless Steel Rat]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

* Bill White <billw@wolfram.com>  on Mon, 19 Jul 1999
| When pgnus checks for new mail/news, I can't do anything in that
| invocation of emacs until pgnus finishes. Keyboard input is
| accumulated until then. When our news server is slow or if there's a
| boatload of email to download, emacs can be useless for quite a while.

Emacs is not threaded (and it probably will never be, at least not in its
current incarnation).  So you have to cheat a little bit: start a second
instance of Emacs just for Gnus.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v0.9.8 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE3k8CHgl+vIlSVSNkRAo8iAJ91Bg/Qsj3MnAhvl5zJiSrkJ5EGZACg2jEN
WrOy63P4CE/M3fmTSgqx63M=
=C79/
-----END PGP SIGNATURE-----

-- 
Rat <ratinox@peorth.gweep.net>    \ When not in use, Happy Fun Ball should be
Minion of Nathan - Nathan says Hi! \ returned to its special container and
PGP Key: at a key server near you!  \ kept under refrigeration.

Re: pgnus commandeers emacs to check mail

[Bill White]

On 19 Jul 1999 20:19:19 -0400
in article <m3673g18c8.fsf@peorth.gweep.net>
Stainless Steel Rat <ratinox@peorth.gweep.net> said:

  ssr> * Bill White <billw@wolfram.com>  on Mon, 19 Jul 1999
  ssr> | When pgnus checks for new mail/news, I can't do anything in that
  ssr> | invocation of emacs until pgnus finishes. Keyboard input is
  ssr> | accumulated until then. When our news server is slow or if there's a
  ssr> | boatload of email to download, emacs can be useless for quite a while.

  ssr> Emacs is not threaded (and it probably will never be, at least
  ssr> not in its current incarnation). So you have to cheat a little
  ssr> bit: start a second instance of Emacs just for Gnus.

Heh - I started running a second emacs just for gnus, but even then I
get bugged by this when writing email. It's like a cat jumping on my
lap when I least expect it (hmm... did Lars use that analogy once upon
a time to describe mail fetching?)

I could increase the time between fetches (it's at 10 minutes now) but
then I find myself hopping over to type 'g' all the time. Just a gnus
junkie, I guess.

Hm - maybe the dual-gnus setup Lars uses would help. Need to dig in
the archives.

Thanks for the idea -

bw
-- 
Bill White . billw@wolfram.com . http://members.wri.com/billw

Re: pgnus commandeers emacs to check mail

[Rajesh Godbole]

Is threading on the roadmap/TODO list?  Is someone actively working on
this?  IMHO it would be a very desirable feature.

>>>>> Stainless Steel Rat writes:

    SSR> Emacs is not threaded (and it probably will never be, at
    SSR> least not in its current incarnation).  

Re: pgnus commandeers emacs to check mail

[Kai Großjohann]

Rajesh Godbole <argv@Sun.COM> writes:

> Is threading on the roadmap/TODO list?  Is someone actively working on
> this?  IMHO it would be a very desirable feature.

I think work is going on with a Guile implementation of Emacs (where
you would get multithreading for free, I gather), but I don't know
the status.  Maybe you can find something in Deja?  There's been a
message recently (within the last 2 or 3 months?).

kai
-- 
Life is hard and then you die.

Re: pgnus commandeers emacs to check mail

[Hrvoje Niksic]

Kai Großjohann <Kai.Grossjohann@CS.Uni-Dortmund.DE> writes:

> Rajesh Godbole <argv@Sun.COM> writes:
> 
> > Is threading on the roadmap/TODO list?  Is someone actively working on
> > this?  IMHO it would be a very desirable feature.
> 
> I think work is going on with a Guile implementation of Emacs (where
> you would get multithreading for free, I gather)

You gather -- from what?

And the Guile Emacs is still far far away.

Re: pgnus commandeers emacs to check mail

[Kai Großjohann]

Hrvoje Niksic <hniksic@srce.hr> writes:

> Kai Großjohann <Kai.Grossjohann@CS.Uni-Dortmund.DE> writes:
> 
> > I think work is going on with a Guile implementation of Emacs (where
> > you would get multithreading for free, I gather)
> 
> You gather -- from what?

Uh, isn't Guile multi-threaded or doesn't it support multithreading?
Hm.  Maybe this was stupid.

kai
-- 
Life is hard and then you die.

Re: pgnus commandeers emacs to check mail

[Didier Verna]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 980 bytes --]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> Uh, isn't Guile multi-threaded or doesn't it support multithreading?
> Hm.  Maybe this was stupid.

        Last time I checked, it wasn't, but this might have changed. However,
getting multithreading "for free" is a bit optimistic. You get multithreading
at the langage level, yes. But that's probably not the most difficult thing to
achieve. The major part of the work is properly designing the way you'll use
multithreading: how many threads ? To do what ? Threads for user commands ?
and so on, with all the non obvious problems it brings, like synchronisation,
mutual exclusion, resources protection etc.

-- 
    /     /   _   _       Didier Verna        http://www.inf.enst.fr/~verna/
 - / / - / / /_/ /     ENST, INFRES C201.1       mailto:verna@inf.enst.fr
/_/ / /_/ / /__ /        46 rue Barrault        Tel.   +33 (1) 45 81 73 46
                       75013 Paris, France      Fax.   +33 (1) 45 81 31 19

Re: pgnus commandeers emacs to check mail

[Robert Bihlmeyer]

Hi,

>>>>> On 21 Jul 1999 13:35:41 +0200
>>>>> Didier Verna <verna@inf.enst.fr> said:

 dv> The major part of the work is properly designing the way you'll
 dv> use multithreading: how many threads ? To do what ?

Once the infrastructure is there, packages like gnus will use it.
Gnus could split mail or score the next group while you're reading
messages.

        Robbe

-- 
Robert Bihlmeyer	reads: Deutsch, English, MIME, Latin-1, NO SPAM!
<robbe@orcus.priv.at>	<http://stud2.tuwien.ac.at/~e9426626/sig.html>

Re: pgnus commandeers emacs to check mail

[Hrvoje Niksic]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> Hrvoje Niksic <hniksic@srce.hr> writes:
> 
> > Kai Großjohann <Kai.Grossjohann@CS.Uni-Dortmund.DE> writes:
> > 
> > > I think work is going on with a Guile implementation of Emacs (where
> > > you would get multithreading for free, I gather)
> > 
> > You gather -- from what?
> 
> Uh, isn't Guile multi-threaded or doesn't it support multithreading?

See Didier's response.  Even if Guile were multi-threaded, you
wouldn't get anything "for free".  You still have to design a sane
interface and port the applications to use that interface, and doing
that is IMHO harder than anything else.

Re: pgnus commandeers emacs to check mail

[Olivier Galibert]

On Tue, Jul 20, 1999 at 10:16:15AM -0700, Rajesh Godbole wrote:
> 
> Is threading on the roadmap/TODO list?  Is someone actively working on
> this?  IMHO it would be a very desirable feature.

What  for  ?  Most people  don't  care about multithreading, they only
want  xemacs  to stop   blocking  while gnus   reads the  active file.
Implementing a    fully-fledged  multithreading  for   _that_  is  way
overkill.

  OG.

Re: pgnus commandeers emacs to check mail

[Rajesh Godbole]

>>>>> Olivier Galibert writes:

    OG> What for ?  Most people don't care about multithreading, they
    OG> only want xemacs to stop blocking while gnus reads the active
    OG> file.  Implementing a fully-fledged multithreading for _that_
    OG> is way overkill.

if the feature becomes available, apps can be written to it, like
parallel fetches with nntp/nnimap/nnml backends in gnus.  multiple
non-blocking apps in different frames.

You build it, they'll come.

Re: pgnus commandeers emacs to check mail

[Michael Sperber [Mr. Preprocessor]]

>>>>> "argv" == Rajesh Godbole <argv@Sun.COM> writes:

argv> Is threading on the roadmap/TODO list?  Is someone actively working on
argv> this?  IMHO it would be a very desirable feature.

This is not a feature at all: it would constitute an overhaul
affecting just about every part oft the current system.  As far as I
know, no.

-- 
Cheers =8-} Chipsy
Friede, Völkerverständigung und überhaupt blabla

Re: pgnus commandeers emacs to check mail

[Karl M. Hegbloom]

>>>>> "Michael" == Michael Sperber <sperber@informatik.uni-tuebingen.de> writes:

>>>>> "argv" == Rajesh Godbole <argv@Sun.COM> writes:
    argv> Is threading on the roadmap/TODO list?  Is someone actively
    argv> working on this?  IMHO it would be a very desirable feature.

    Michael> This is not a feature at all: it would constitute an
    Michael> overhaul affecting just about every part oft the current
    Michael> system.  As far as I know, no.

 I guess if someone wanted to research it and learn how it might be
 done, Guile Scheme might be a good place to look.  Certainly there
 are other schemes and lisps with threading...

 guile, rscheme, ecolisp, scheme48

 I'm a few years away from that study, I've found.  I tried... and am
 actually on the track, but it's a tall pile of books.