Re: TODO idea:

[Wesley Hardaker <whardake@sphysdec1.unil.ch>]

>>>>> On 18 Jun 1997 14:09:41 +0200, Lars Magne Ingebrigtsen <larsi@gnus.org> said:

Lars> Uhm.  Nope.  nnml is nnml, while nnmh is supposed to be mh
Lars> compliant.  nnml will never be able to coexist with mh.  That
Lars> the point of nnmh.

Which is exactly why I originally suggested (a while back in this
thread) that there should be a nnmlmh that dealt with both.  I think
you missed the point of the discussion, which was that there are a lot
of people (ok, me and like 2 others) that want to be able to read mail
without having to jump into emacs to do it (Ok...  even worse, as I
don't need to that much anymore myself, but I will again in 3-4
months).  Anyway, if we had a backend that had the speed of nnml in
gnus, but the command line interface of nnml we would be in heaven.
The problem, of course, comes generating the nnml nov files.  This has
been our point of discussion...  Add the possibility (ie, a toggle)
into nnml to generate the .mh_sequence file (very trivial really) or
create a new backend like nnmlmh instead that was a conglomerate of
both backends.  How well does the nnoo stuff work, he says with an
evil grin, can you do nnmhml = nnmh&nnml and then overwrite the
necessary pieces?  (grin)

As a brief example, since you don't use mh:

I'm at work, reading mail in gnus...  Lets work with specifically my
inbox for today.  I read messages 10-15 but never get to 16-18 (and
say, missed #8).  This is reference #1

I go home.  I log in to work and want to quickly check mail over a
14.4k line.  Emacs is quite nice as an attached frame to xemacs over a
14.4k line, but still command line is generally faster and I'm not
here long and don't want to wait, so I opt to do mh calls instead.

  scan +inbox unseen

doesn't work.  Normally, in mh, this would show me the messages
8,16-18 by reading the file .mh_sequences.  This file would look
something like:

  cur: 15
  unseen: 8, 16-18

If gnus had written this out at #1 above, I would be in heaven here as
I could then go on and read, say, article 17.  Which would change the
unseen sequence to 8,16,18.  Say, then, I did an incorperate of the
new mail while at home in mh mode and this added a article 19.  A scan
(as above) shows me the subject and it looks boring (ie, its not from
the ding list), so I don't read it.

I go back to work the next day and start up gnus.  Now, Gnus gets
screwed here because I did stuff behind its back.  First, I read #17,
this would be easy to detect in gnus (check the date stamp on the
mh_sequence file and update the read list if date is newer than
.newsrc.eld).  The harder one to deal with is #19, which got
incorperated by mh instead of gnus.  It would have to realize this
message exists (scanning the dir) and generate the appropriate nov
lines for any new messages...

Now, do you still think this is a completely worthless idea and I
should be using nnmh instead (annoyingly slow) when I spend the
majority of my time at work in gnus and only dabble in mh
occasionally (I used to use it constantly before switching to nnml)?
The ideas above wouldn't be that hard to implement (why am I talking
instead of implementing, I know, I know...) I don't think.  They could
either be thrown in as (setq gnus-nnml-be-nice-to-mh t) or as a new
backend that spoke both languages.  Its fairly simple, so most people
have said the variable idea would be a better approach.

:-)
Wes

-- 
"Ninjas aren't dangerous.  They're more afraid of you than you are of them."