TODO idea:

TODO idea:

[Wesley Hardaker]

You know what we need...  (ha ha ha)...  Something to generate a
summary buffer of mail (or news) you haven't read.  IE, something like
a 'biff' but for the gnus backends.  That way you could incorperate
mail using whatever methods, then set some variable like
(setq gnus-biff-groups '(nnml:inbox nnml:other)) which would then
watch those groups and every time a new message arrived in them, it
would through a description line to the end of the '*BIFF*' buffer or
something...

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

Re: TODO idea:

[Lars Balker Rasmussen]

Wesley Hardaker <whardake@sphysdec1.unil.ch> writes:
[gnus biff]

Yes!  I hate my xbiff going off when a mail arrives on sun-managers or
some of the other newsgroup-like mailing lists I'm on, but other mail I
have to read immediately.  It'd be nice if you could solve this problem
without resorting to procmail.  (Though Randal posted something
procmail-ish a while ago which looked very nice indeed, I don't really
want to spend the time setting it all up.  Sigh.)
-- 
Lars Balker Rasmussen, Software Engineer, Mjolner Informatics ApS
lbr@mjolner.dk

Re: TODO idea:

[Kai Grossjohann]

>>>>> Lars Balker Rasmussen writes:

  Lars> Yes!  I hate my xbiff going off when a mail arrives on
  Lars> sun-managers or some of the other newsgroup-like mailing lists
  Lars> I'm on, but other mail I have to read immediately.

I used to use the following once:

In the X resources put the following:

,-----
| XBiff*checkCommand:     /home-local/grossjoh/bin/check-for-new-mail
| XBiff*onceOnly:         true
`-----

And the check-for-new-mail script looks like this:

,-----
| #!/bin/sh
| if ( from | egrep -v 'debian' >/dev/null 2>&1 )
| then
|     exit 0;
| else
|     exit 2;
| fi
`-----

I think it's clear how to adapt this from debian to sun-managers :-)

I'm not sure if you need the onceOnly X resource, just try it.

kai
-- 
Some people say that language is for communication.
I think communcation is in spite of language.

Re: TODO idea:

[Lars Magne Ingebrigtsen]

Wesley Hardaker <whardake@sphysdec1.unil.ch> writes:

> You know what we need...  (ha ha ha)...  Something to generate a
> summary buffer of mail (or news) you haven't read.  IE, something like
> a 'biff' but for the gnus backends.  That way you could incorperate
> mail using whatever methods, then set some variable like
> (setq gnus-biff-groups '(nnml:inbox nnml:other)) which would then
> watch those groups and every time a new message arrived in them, it
> would through a description line to the end of the '*BIFF*' buffer or
> something...

That's not really a Gnus matter, though.  You just need something run
periodically that sniffs all the directories and see what's up.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: TODO idea:

[Wesley Hardaker]

>>>>> On 06 Jun 1997 19:36:17 +0200, Lars Magne Ingebrigtsen <larsi@gnus.org> said:

Lars> That's not really a Gnus matter, though.  You just need
Lars> something run periodically that sniffs all the directories and
Lars> see what's up.

Well, the problem is that I have gnus incorperate spool messages every
15 minutes or so. This means, there are two places with new mail:  the
.spool files and the actually nnml directory.  Now, I've been wanting
to write a nnmlmh backend for a long time, but haven't had the time.
This would combine nnml and nnmh backends so that it would essentially
be a nnml that would additionally save a .mhsequence file to update
the unseen sequence (which is how mh marks new messages.  That way you
can do a 'scan +ding unseen' to see everything in the ding group you
haven't read yet with gnus.  Hence, you can than use a biff type
program to use this information.  As is now, there is no way outside
of emacs to figure out what has been read or unread in a nnml group
(easily that is)...


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

Re: TODO idea:

[Jason R Mastaler]

Wesley Hardaker <whardake@sphysdec1.unil.ch> writes:

> Well, the problem is that I have gnus incorperate spool messages every
> 15 minutes or so. This means, there are two places with new mail:  the
> ..spool files and the actually nnml directory.  Now, I've been wanting
> to write a nnmlmh backend for a long time, but haven't had the time.
> This would combine nnml and nnmh backends so that it would essentially
> be a nnml that would additionally save a .mhsequence file to update
> the unseen sequence (which is how mh marks new messages.  That way you
> can do a 'scan +ding unseen' to see everything in the ding group you
> haven't read yet with gnus.  Hence, you can than use a biff type
> program to use this information.  As is now, there is no way outside
> of emacs to figure out what has been read or unread in a nnml group
> (easily that is)...

Is it necessary to write a new backend?  Why not just code the unseen
sequences functionality into nnmh and optionally, nnml?

   Jason R. Mastaler                      jason@mastaler.com

Re: TODO idea:

[Wesley Hardaker]

>>>>> On 09 Jun 1997 20:58:20 -0600, Jason R Mastaler <jason@mastaler.com> said:

Jason> Is it necessary to write a new backend?  Why not just code the
Jason> unseen sequences functionality into nnmh and optionally, nnml?

Well, that was the original idea technically...  nnml can be
considered nnmh really...  its just better, as nnmh doesn't keep
records of things.  Anyway, It should be a new interface as not
everyone wants to create the new file, there for it should be a
super-class (what is the oo stuff called in nnoo?) of nnml...  But I
definately do want it in nnml, not nnmh, as its a better interface for
gnus...

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

Re: TODO idea:

[Jason R Mastaler]

Wesley Hardaker <whardake@sphysdec1.unil.ch> writes:

> Well, that was the original idea technically...  nnml can be
> considered nnmh really...  its just better, as nnmh doesn't keep
> records of things.  Anyway, It should be a new interface as not
> everyone wants to create the new file, there for it should be a
> super-class (what is the oo stuff called in nnoo?) of nnml...  But I
> definately do want it in nnml, not nnmh, as its a better interface for
> gnus...

Not keeping records of some things (like an active file) can sometimes
be useful.  I specifically use nnmh so I can read all my mail outside
Gnus if I want.  Back to the issue of a new backend.  Being ignorant
of the design issues involved, I'll ask why not just give the user the
choice of adding the unseen sequences file functionality to the
current backend(s) if she wants to use it? (extra option or something)
-- it seems like it would more flexible that way. 

And yes I agree, for *Gnus*, nnml is a better interface.

   Jason R. Mastaler                      jason@mastaler.com

Re: TODO idea:

[Wesley Hardaker]

>>>>> On 10 Jun 1997 21:49:35 -0600, Jason R Mastaler <jason@mastaler.com> said:

Jason> Not keeping records of some things (like an active file) can
Jason> sometimes be useful.  I specifically use nnmh so I can read all
Jason> my mail outside Gnus if I want.  Back to the issue of a new
Jason> backend.  Being ignorant of the design issues involved, I'll
Jason> ask why not just give the user the choice of adding the unseen
Jason> sequences file functionality to the current backend(s) if she
Jason> wants to use it? (extra option or something)
Jason> -- it seems like it would more flexible that way. 

I suppose that would probably be fine too, but it does need to be done
for both actually...  You *can* use nnmh, so you can read mail outside
news as you stated, however, nnml is a much nice backend for gnus (as
its quite a bit faster).  And, since the file format is pretty much
identicaly, there is no reason you can't use the nnml backend and read
the messages using regular mh commands.  (its the 'inc' that will
break things, if you do one).  I actually want to stick with nnml and
have it write a .mh_sequence file is all...

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

Re: TODO idea:

[Paul Graham]

i also like being able to us the mh stuff with nnml.  that's one of the
reasons i don't use emacs to incorporate my mail into the folders -- if i'm
reading ``out-of-band'' it's probably inconvenient to start emacs.

    jason> Not keeping records of some things (like an active file) can
    jason> sometimes be useful.  I specifically use nnmh so I can read all
    jason> my mail outside Gnus if I want.

    wes> You *can* use nnmh, so you can read
    wes> mail outside news as you stated, however, nnml is a much nice
    wes> backend for gnus (as its quite a bit faster).  And, since the file
    wes> format is pretty much identicaly, there is no reason you can't use
    wes> the nnml backend and read the messages using regular mh commands.


-- 
 paul
    pjg@acsu.Buffalo.EDU    |public keys at:
                            |     http://urth.acsu.Buffalo.EDU/~pjg/key.html
    if the above contains opinions they are mine unless marked otherwise.

Re: TODO idea:

[Lars Magne Ingebrigtsen]

Paul Graham <pjg@acsu.buffalo.edu> writes:

> i also like being able to us the mh stuff with nnml. 

nnml will never be able to interact with mh, but nnmh might become
more clever and handle mh stuff better.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: TODO idea:

[Wesley Hardaker]

>>>>> On 17 Jun 1997 17:34:36 +0200, Lars Magne Ingebrigtsen <larsi@gnus.org> said:

Lars> Paul Graham <pjg@acsu.buffalo.edu> writes:
>> i also like being able to us the mh stuff with nnml. 

Lars> nnml will never be able to interact with mh, but nnmh might become
Lars> more clever and handle mh stuff better.

My point is that it would be nice to have a combination of both, so
that nnml *will* recognize mh style stuff so you can use both at once
(ie, nnml would notice a .mh_sequence file that had been updated, and
re-generate its active files or something (and would save the
.mh_sequence file when it finished...  As people said, this should be
an option of course))

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

Re: TODO idea:

[Lars Magne Ingebrigtsen]

Wesley Hardaker <whardake@sphysdec1.unil.ch> writes:

> My point is that it would be nice to have a combination of both, so
> that nnml *will* recognize mh style stuff so you can use both at once
> (ie, nnml would notice a .mh_sequence file that had been updated, and
> re-generate its active files or something (and would save the
> .mh_sequence file when it finished... 

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

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: TODO idea:

[David S. Goldberg]

[-- Attachment #1: Type: text/plain, Size: 1109 bytes --]

This is probably not what is desired, though it may be a part of it.
A not very long time ago, I also cared about keeping gnus and mh in
sync.  For incoming stuff, if I used MH to inc a folder, I had as part
of my gnus-select-group-hook (I think, though it may have been a
different hook) a call to nnml-generate-nov-databases-1.  Then, to
have gnus update the unseen sequence, I used the lisp found at the end
of this message.  If gnus incorporated the mail (which was becoming
more and more the normal case) I punted on the unseen sequence stuff.
I wanted to get it done, but none of the advices I put on the
nnml-accept functions ever seemed to work reliably.  For what its
worth, back then (I'm pretty sure the last time I ever bothered with
this, it was still September) nnmh didn't do anything with the mh
sequences either (does it now?).  Anyway, if this helps someone make
gnus deal better with mh, so much the better.  If not, I apologize for
the waste of bandwidth.

--
Dave Goldberg
Post: The Mitre Corporation\MS B305\202 Burlington Rd.\Bedford, MA 01730
Phone: 617-271-3887
Email: dsg@mitre.org


[-- Attachment #2: Type: text/plain, Size: 2386 bytes --]

(defun dsg-gnus-mh-make-seen (&optional doall)
  (if (eq (car
	   (gnus-group-method (if (eq major-mode 'gnus-group-mode)
				       (gnus-group-group-name)
				     gnus-newsgroup-name)))
	  'nnml)
      (let ((mark-cmd (concat mh-progs "/mark"))
	    (fldr-cmd (concat mh-progs "/folder"))
	    (fldr
	     (if (eq major-mode 'gnus-group-mode)
		 (substring (gnus-group-group-name) 5)
	       (substring nnml-current-directory (length mh-user-path)))))
	(call-process fldr-cmd nil nil nil
		      "-push" (concat "+" fldr))
	(cond ((eq doall 'all)
	       (call-process mark-cmd nil nil nil
			     "-sequence" "unseen" "-delete" "all"))
	      ((integerp doall)
	       (call-process mark-cmd nil nil nil
			     "-sequence" "unseen" "-delete"
			     (concat "1-" (int-to-string doall))))
	      (t
	       (call-process mark-cmd nil nil nil
			     "-sequence" "unseen" "-delete"
			     (int-to-string (gnus-summary-article-number)))))
	(call-process fldr-cmd nil nil nil "-pop"))))

(defadvice gnus-group-catchup (before make-seen activate)
  "Mark all messages as seen in MH."
  (dsg-gnus-mh-make-seen 'all))

(defadvice gnus-group-catchup-current (before make-seen activate)
  "Mark all messages as seen in MH."
  (dsg-gnus-mh-make-seen 'all))

(defadvice gnus-group-catchup-current-all (before make-seen activate)
  "Mark all messages as seen in MH."
  (dsg-gnus-mh-make-seen 'all))

(defadvice gnus-summary-catchup (before make-seen activate)
  "Mark all messages as seen in MH."
  (dsg-gnus-mh-make-seen 'all))

(defadvice gnus-summary-catchup-all (before make-seen activate)
  "Mark all messages as seen in MH."
  (dsg-gnus-mh-make-seen 'all))

(defadvice gnus-summary-catchup-all-and-exit (before make-seen activate)
  "Mark all messages as seen in MH."
  (dsg-gnus-mh-make-seen 'all))

(defadvice gnus-summary-catchup-and-exit (before make-seen activate)
  "Mark all messages as seen in MH."
  (dsg-gnus-mh-make-seen 'all))

(defadvice gnus-summary-catchup-and-goto-next-group (before make-seen activate)
  "Mark all messages as seen in MH."
  (dsg-gnus-mh-make-seen 'all))

(defadvice gnus-summary-catchup-to-here (before make-seen activate)
  "Mark all messages as seen in MH."
  (dsg-gnus-mh-make-seen (gnus-summary-article-number)))

(defadvice gnus-summary-mark-as-expirable (before make-seen activate)
  "Mark the message as seen in MH."
  (dsg-gnus-mh-make-seen))

Re: TODO idea:

[Wesley Hardaker]

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

Re: TODO idea:

[Paul Franklin]

>>>>> Wesley Hardaker writes:

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

Hmm.  I thought the proposal was to use slocal or procmail or
something else to deliver mail & update .mh_sequence files; gnus would
then scan these files for unseen mail.  Personally, I'm against this
because it will make things worse for people with slow (networked)
file systems like me.  (Having one file per nnml spool, similar to the
active file, seems promising to me.)  And you have to solve the last
message removal problem for this to work well.

You seem to want to do this the other way around, which would mean
that mh won't see your mail unless you have gnus running and a gnus
daemon getting your mail for you, meaning you have to hope emacs or
the machine it's running on doesn't die, but it could work.

Oh, I just read your example.  You want _both_ directions.  That means
you have to solve all of the aforementioned problems (except gnus
daemons) plus figure out how to lock the .mh_sequence files.  I would
assume mh already does this?

I think "very trivial really" couldn't be farther from the truth.

If I remember right, nnml is directly on top of nnmh, which means that
nnml == nnml+nnmh.  I tried to understand the nnoo stuff last summer
and failed; I may try again soon.

--Paul

Re: TODO idea:

[Darren/Torin/Who Ever...]

-----BEGIN PGP SIGNED MESSAGE-----

Paul Franklin, in an immanent manifestation of deity, wrote:
>You seem to want to do this the other way around, which would mean
>that mh won't see your mail unless you have gnus running and a gnus
>daemon getting your mail for you, meaning you have to hope emacs or
>the machine it's running on doesn't die, but it could work.

Well, what I'm looking for is a little simpler than this.  I want to use
mailagent to deliver to all my folders.  I have already aliased inc,
rmm, and refile out of the way.  It's interesting that you can't specify
a sortmproc.  This way, I can't accidently do anything to my folders and
leaves only mailagent and gnus doing stuff to my folders.

I can still look at messages, pipe them into commands, and have cron do
unspeakable acts upon them though.

It makes it much easier that I don't care about last article removal or
unseen sequences.  Mailagent handles all additions and Gnus handles all
moves and deletions (expirations).

My problem is that Gnus keeps some of it's stuff in memory without
checking to see if something else has touched it.  I'm only using nnml
on a few experimental folders that I keep backups on.  I haven't lost
mail yet but they are rather low volume lists.  I fear hooking
perl5-porters or debian-devel into this though.

Darren
- -- 
<torin@daft.com> <http://www.daft.com/~torin> <torin@debian.org> <torin@io.com>
Darren Stalder/2608 Second Ave, @282/Seattle, WA 98121-1212/USA/+1-800-921-4996
@ Do you have your clothes on? I probably don't. Take yours off. Feel better. @
@ Sysadmin, webweaver, postmaster for hire.  C/Perl/CGI programmer and tutor. @

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3
Charset: noconv
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface

iQCVAwUBM6oAE44wrq++1Ls5AQG/MwP/X46lkCcGfkz9UJdCqzuTgwCdp1M+0jmo
NpHfT1IkrXY1cpOsBLiU/zOBF/rHYzvjwb43nWwe3jPiUwwxdTJ138wX6dy4l7gj
zNRyE0J1ymtWuEYrZ1DjsjbMJ4ilnYZ/50iN4vPmfglQkpH5j6s2ze23I1voel57
8lH6Z4O6Yrk=
=NQWm
-----END PGP SIGNATURE-----

Re: TODO idea:

[Scott Blachowicz]

Wesley Hardaker <whardake@sphysdec1.unil.ch> wrote:

> 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

Make that 3 :-).

Let's try a modification of your scenario to illustrate a problem...

>...
>   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.

Let's say instead that you read article 18 instead of 17.  Then you end up
with an unseen seq of 8,16,17 and when you do your 'inc', you end up with
a new article 18 (instead of 19).

> I go back to work the next day and start up gnus.  Now, Gnus gets
> screwed here because I did stuff behind its back.

True...but the problem is more subtle.  The unseen sequence is the same,
but the messages it refers to are different.  I suppose that could be
solved by comparing Message-ID's of all of the messages when the
.mh_sequences file is newer than the NOV file.  Or just compare the update
times on the individual message files with the update time on the
.mh_sequences file and update the newer messages, remove ones that no
longer exist, etc.

Or we could put a hack into mh/nmh that makes it so that message numbers
are not reused (unless you do a 'pack' or some other command that
explicitly, intentionally does so)?

All of the above problems are basically why I stopped trying to use an emacs
newsreader to read my email (from gnus4 days and the "mixspool" hack that I'd
put into THAT).  Now I've been using exmh and nmh directly...

Scott Blachowicz  Ph: 206/283-8802x240   Mathsoft (Data Analysis Products Div)
                                         1700 Westlake Ave N #500
scott@statsci.com                        Seattle, WA USA   98109
Scott.Blachowicz@seaslug.org

Re: TODO idea:

[Wesley Hardaker]

>>>>> On Thu, 19 Jun 1997 11:32:29 -0700, Scott Blachowicz <scott@apple.statsci.com> said:

Scott> Let's say instead that you read article 18 instead of 17.  Then
Scott> you end up with an unseen seq of 8,16,17 and when you do your
Scott> 'inc', you end up with a new article 18 (instead of 19).

You forgot to mention you deleted 18 also, not just read it.

However, my general thoughts on this is that if you do a mh 'inc', you
should simply never do a mh 'rmm last'.  Period.  There is no way to
protect gnus from this, so it should be done.  Ever.  Now, that aside,
yes it could be implemented by doing date checking, but hey, thats
back to slowness again I think...

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

Re: TODO idea:

[Scott Blachowicz]

>>>>> "Wes" == Wesley Hardaker <whardake@sphysdec1.unil.ch>
 Scott> Let's say instead that you read article 18 instead of 17.  Then
 Scott> you end up with an unseen seq of 8,16,17 and when you do your
 Scott> 'inc', you end up with a new article 18 (instead of 19).
 Wes> You forgot to mention you deleted 18 also, not just read it.
True, but I was thinking that while writing - does that count? :-))

 Wes> However, my general thoughts on this is that if you do a mh 'inc', you
 Wes> should simply never do a mh 'rmm last'.  Period.

I wonder how hard it would be to get mh/nmh to use different methods to
decide what a new message is to be numbered...

1) add a "lastused" sequence to .mh_sequence that it updates and uses to
   determined what the next message is to be called.

2) add checks to prevent 'rmm' from really deleting the 'last' message?
   Maybe just truncate the file? Or rename it to some special name
   (e.g. "=383" instead of ",383"), then it's existence could be used as a
   marker similar to that "lastused" sequence?

I think I like #1 better.

Scott Blachowicz  Ph: 206/283-8802x240   Mathsoft (Data Analysis Products Div)
                                         1700 Westlake Ave N #500
scott@statsci.com                        Seattle, WA USA   98109
Scott.Blachowicz@seaslug.org

Re: TODO idea:

[Richard Coleman]

> I wonder how hard it would be to get mh/nmh to use different methods to
> decide what a new message is to be numbered...
> 
> 1) add a "lastused" sequence to .mh_sequence that it updates and uses to
>    determined what the next message is to be called.
> 
> 2) add checks to prevent 'rmm' from really deleting the 'last' message?
>    Maybe just truncate the file? Or rename it to some special name
>    (e.g. "=383" instead of ",383"), then it's existence could be used as a
>    marker similar to that "lastused" sequence?
> 
> I think I like #1 better.

It would be very difficult to change the way that MH/nmh handles
folders.  The code is not very modular.  I've been working on cleaning
this up for nmh-0.15.

So it might be possible in the future, but not now.

Richard Coleman
coleman@math.gatech.edu

Re: TODO idea:

[Lars Magne Ingebrigtsen]

Wesley Hardaker <whardake@sphysdec1.unil.ch> writes:

> 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 I neglected to mention that nnmh will start taking
.mh_sequence into account, and will keep it updated.

However, nnml will never be doing any of this.  nnml is specifically
designed to be as efficient as I can make it, and it assumes that no
other external agency ever touches its data.  This will never change.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: TODO idea:

[Richard Coleman]

> > 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 I neglected to mention that nnmh will start taking
> .mh_sequence into account, and will keep it updated.

This will be difficult to do properly.

First of all, the name of the sequence file (default is .mh_sequence)
can be changed in the MH/nmh configuration file ".mh_profile".

Second, there are 2 kinds of sequences.  The most common is a
"public" sequence, which is kept in the .mh_sequence (or equivalent)
file, for the given folder.  The other is a "private" sequence
which is kept in the users MH/nmh global "context" file (whose
name can also be changed in the .mh_profile).

And to make matters worse, the name of the MH/nmh configuration file
(default is .mh_profile) can be changed using environment variables.

MH/nmh has a considerable amount of code to keep all this straight.

Richard Coleman          (nmh developer)
coleman@math.gatech.edu

Re: TODO idea:

[Scott Blachowicz]

Richard Coleman <coleman@math.gatech.edu> wrote:

> Second, there are 2 kinds of sequences.  The most common is a
> "public" sequence, which is kept in the .mh_sequence (or equivalent)
> file, for the given folder.  The other is a "private" sequence
> which is kept in the users MH/nmh global "context" file (whose
> name can also be changed in the .mh_profile).

...and via the environment variable MHCONTEXT (I use that one in some utility
scripts, background daemons & such to avoid getting in the way of my normal,
interactive sessions).

> MH/nmh has a considerable amount of code to keep all this straight.

Any idea if there's any existing elisp code to put an API over MH sequence
manipulations?  I suppose mh-e probably uses external MH commands...any others
whose code could be "leveraged"?

Scott Blachowicz  Ph: 206/283-8802x240   Mathsoft (Data Analysis Products Div)
                                         1700 Westlake Ave N #500
scott@statsci.com                        Seattle, WA USA   98109
Scott.Blachowicz@seaslug.org

Re: TODO idea:

[Lars Magne Ingebrigtsen]

Richard Coleman <coleman@math.gatech.edu> writes:

> > I think I neglected to mention that nnmh will start taking
> > .mh_sequence into account, and will keep it updated.
> 
> This will be difficult to do properly.

Yes, probably, but if mh can do it, nnmh can do it.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: TODO idea:

[Richard Coleman]

> > > I think I neglected to mention that nnmh will start taking
> > > .mh_sequence into account, and will keep it updated.
> > 
> > This will be difficult to do properly.
> 
> Yes, probably, but if mh can do it, nnmh can do it.

Of course it can.  I just wanted you to know that it
is more difficult than just updating the .mh_sequence
file.  Gnus will need to read the MH/nmh configuration
files and use any information there.

Also, MH and nmh are developed by different groups of
people.  There are some minor incompatibilities between
them.

Also nmh will start locking folders and its context files
to make things more reliable.  Gnus would need to also do
similar locking.

I can answer any questions about MH or nmh you may have.
Unfortunately many of the details are not documented (except
in the source code).

Richard Coleman
coleman@math.gatech.edu

Re: TODO idea:

[Jason R Mastaler]

Richard Coleman <coleman@math.gatech.edu> writes:

> > > > I think I neglected to mention that nnmh will start taking
> > > > .mh_sequence into account, and will keep it updated.
> > > 
> > > This will be difficult to do properly.
> > 
> > Yes, probably, but if mh can do it, nnmh can do it.
> 
> Of course it can.  I just wanted you to know that it
> is more difficult than just updating the .mh_sequence
> file.  Gnus will need to read the MH/nmh configuration
> files and use any information there.

Does it really need to?

This is assuming that total MH/nmh user compatability is necessary for
nnmh before it can use sequences.  I think one "supported" location
for the public and private sequences files will suffice for nnmh.
I.e, if Gnus users want nnmh to update the sequences file, they have
to use the default names and locations for them (.mh_sequences, etc).
Of course, I wouldn't complain if nnmh was made to handle sequences
in the complex fashion that nmh/MH does, but at the same time, I don't
think the interest to add basic sequences functionality to nnmh 
should be deterred.

Re: TODO idea:

[Darren/Torin/Who Ever...]

-----BEGIN PGP SIGNED MESSAGE-----

Lars Magne Ingebrigtsen, in an immanent manifestation of deity, wrote:
>However, nnml will never be doing any of this.  nnml is specifically
>designed to be as efficient as I can make it, and it assumes that no
>other external agency ever touches its data.  This will never change.

How about a middle of the road backend?  Something that won't be as fast
as nnml since it talks to mh and lets other people update some of its
data but it has overview and active files?

(I've tried to come up with a clever nnm? but have failed so far.)

Darren
- -- 
<torin@daft.com> <http://www.daft.com/~torin> <torin@debian.org> <torin@io.com>
Darren Stalder/2608 Second Ave, @282/Seattle, WA 98121-1212/USA/+1-800-921-4996
@ Do you have your clothes on? I probably don't. Take yours off. Feel better. @
@ Sysadmin, webweaver, postmaster for hire.  C/Perl/CGI programmer and tutor. @

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3
Charset: noconv
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface

iQCVAwUBM622vY4wrq++1Ls5AQFPiwP8CfEmpkqbfNoFniZvRM2Q9FIuMtwU0lhx
bvsl9XbLZCh+LLZlkbPO7WMQHH31j8dexQQhjn//TT9l2+e9lbUwfZD5TooC3Idz
VOLxqThPzdrEVbBThjJTJ95XP8c8o/ZPnlxkuDWV+B+zDkDV0rrXXEGB2faCHOh0
6JER+SqyCOI=
=DhXk
-----END PGP SIGNATURE-----

Re: TODO idea:

[Lars Magne Ingebrigtsen]

Jason R Mastaler <jason@mastaler.com> writes:

> Not keeping records of some things (like an active file) can sometimes
> be useful.  I specifically use nnmh so I can read all my mail outside
> Gnus if I want.  Back to the issue of a new backend.  Being ignorant
> of the design issues involved, I'll ask why not just give the user the
> choice of adding the unseen sequences file functionality to the
> current backend(s) if she wants to use it?

There's nobody stopping anyone from adding such functionality.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: TODO idea:

[anonymous]

ttol2o.fsf@mastaler.com> <riiuzemnaq.fsf@urth.acsu.buffalo.edu> <m27mftkzub.fsf@proletcult.slip.ifi.uio.no>
Mime-Version: 1.0 (generated by tm-edit 7.105)
Content-Type: multipart/mixed;
 boundary="Multipart_Wed_Jun_25_10:33:51_1997-1"
Content-Transfer-Encoding: 7bit
From: Arne Elofsson <arne@rune.biokemi.su.se>
Date: 25 Jun 1997 10:33:51 +0200
Message-ID: <ygbzpsf2ia8.fsf@rune.biokemi.su.se>
Lines: 36
X-Newsreader: Gnus v5.4.37/XEmacs 19.15
Path: rune.biokemi.su.se
NNTP-Posting-Host: rune.biokemi.su.se

--Multipart_Wed_Jun_25_10:33:51_1997-1
Content-Type: text/plain; charset=US-ASCII

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Paul Graham <pjg@acsu.buffalo.edu> writes:
> 
> > i also like being able to us the mh stuff with nnml. 
> 
> nnml will never be able to interact with mh, but nnmh might become
> more clever and handle mh stuff better.
> 

I think the best solution is the one I use, and I would really like
moer people to use it. I use mh for mailsplitting, and creation of
active and .overview files. Then I use nnml for reading mails.

This is very convinent, fast etc. 
1) nnml is the fastest way to read email in gnus.
2) The splitting only takes a few seconds to I can have a crontab to be
run every five minutes.
3) I can use mh to read, pipe emails etc. (for instance sending nasty
emails to spam sites)

if you are interested I'll send you the simple scripts

arne

--Multipart_Wed_Jun_25_10:33:51_1997-1
Content-Type: text/plain; charset=US-ASCII

-----------------------------------------------------------------
 Arne Elofsson     arne@bimbo.biokemi.su.se http://www.biokemi.su.se/~arne/
 Tel:+46(0)8-161553      Dept of Biochemistry, Stockholm University
 Fax:+46(0)8-153679	 10691 Stockholm, Sweden
--Multipart_Wed_Jun_25_10:33:51_1997-1--

Re: TODO idea:

[Paul Franklin]

>>>>> Arne Elofsson <arne@rune.biokemi.su.se> writes:

 > I think the best solution is the one I use, and I would really like
 > more people to use it. I use mh for mailsplitting, and creation of
 > active and .overview files. Then I use nnml for reading mails.

Hmm.  But nnml doesn't do any locking of active or .overview files, so
you're probably introucing a really nasty race condition by doing
this.

This idea gests proposed reasonably frequently, but has never gained
widespread acceptance because of the potential for bad things
happening.

--Paul

Re: TODO idea:

[anonymous]

0625083410.17735.qmail@sunsite.auc.dk> <r9qpvtaa0oi.fsf@edison.cs.washington.edu>
Mime-Version: 1.0 (generated by tm-edit 7.105)
Content-Type: multipart/mixed;
 boundary="Multipart_Thu_Jun_26_11:38:21_1997-1"
Content-Transfer-Encoding: 7bit
From: Arne Elofsson <arne@rune.biokemi.su.se>
Date: 26 Jun 1997 11:38:21 +0200
Message-ID: <ygb205pr9f6.fsf@rune.biokemi.su.se>
Lines: 49
X-Newsreader: Gnus v5.4.37/XEmacs 19.15
Path: rune.biokemi.su.se
NNTP-Posting-Host: rune.biokemi.su.se

--Multipart_Thu_Jun_26_11:38:21_1997-1
Content-Type: text/plain; charset=US-ASCII

Paul Franklin <paul@cs.washington.edu> writes:

> >>>>> Arne Elofsson <arne@rune.biokemi.su.se> writes:
> 
>  > I think the best solution is the one I use, and I would really like
>  > more people to use it. I use mh for mailsplitting, and creation of
>  > active and .overview files. Then I use nnml for reading mails.
> 
> Hmm.  But nnml doesn't do any locking of active or .overview files, so
> you're probably introucing a really nasty race condition by doing
> this.
> 
I do not think this is a major problem. The active file and .overview
files in all folders that are touched since the last time I run my
splitting program is recreated from outside gnus. So if nnml changes
some of these files it is no big deal.

> This idea gests proposed reasonably frequently, but has never gained
> widespread acceptance because of the potential for bad things
> happening.



That is true. The only problem I have had is that if you happen to
move/remove your last file in a folder you will miss the next new
new message in that folder. 

(setq nnmail-keep-last-article t)

Helps somehow but not if I remove that file with mh from outside gnus.

It would be nice to have nnml to change the last read message in a
folder to the last message in the active file. I'll hack that someday.


arne


--Multipart_Thu_Jun_26_11:38:21_1997-1
Content-Type: text/plain; charset=US-ASCII

-----------------------------------------------------------------
 Arne Elofsson     arne@bimbo.biokemi.su.se http://www.biokemi.su.se/~arne/
 Tel:+46(0)8-161553      Dept of Biochemistry, Stockholm University
 Fax:+46(0)8-153679	 10691 Stockholm, Sweden
--Multipart_Thu_Jun_26_11:38:21_1997-1--

Re: TODO idea:

[Paul Graham]

(what's this anonymous@sunsite stuff)

argh.  this sounds like a recipe for disaster.  i think my system is
somewhat risky but this sound flagrantly dangerous.  i lock the active file
in nnheader.el and it to decide what the next file should be named (much
like the news system) but i still sometimes have a collision (for reasons
completely unobvious to me).  the insertion code won't overwrite an
existing file though so it's not fatal.  i just ignore the ``.overview has
changed'' messages.


    arne> I do not think this is a major problem. The active file and
    arne> .overview files in all folders that are touched since the last
    arne> time I run my splitting program is recreated from outside
    arne> gnus. So if nnml changes some of these files it is no big deal.

    >> This idea gests proposed reasonably frequently, but has never gained
    >> widespread acceptance because of the potential for bad things
    >> happening.

people propose it because it's a good idea.  of course if gnus could
incorporate 1,000 messages in < 30 seconds on my machine i'd use gnus
movemail.

-- 
 paul
    pjg@acsu.Buffalo.EDU    |public keys at:
                            |     http://urth.acsu.Buffalo.EDU/~pjg/key.html
    if the above contains opinions they are mine unless marked otherwise.

Re: TODO idea:

[Paul Franklin]

>>>>> Paul Graham writes:

 > (what's this anonymous@sunsite stuff)

Some gateway appears to be chopping off headers when it sees long
References: lines.  I think it may be related to the newsgroup version
of the list at sunsite.???.dk.  I solved it for my own posts a while
back by adding
	(to-address . "ding@gnus.org")
to emacs.ding's group parameters.

 >     >> This idea gests proposed reasonably frequently, but has never gained
 >     >> widespread acceptance because of the potential for bad things
 >     >> happening.

 > people propose it because it's a good idea.  of course if gnus could
 > incorporate 1,000 messages in < 30 seconds on my machine i'd use gnus
 > movemail.

We all agree it's useful.  (I think.  I agree, anyways.)  That's why
I've tried to come up with an alternative that's not broken, and why I
hope that some day I'll actually find time to code it.  (Sigh.)

--Paul

Re: TODO idea:

[Paul Franklin]

>>>>> Jason R. Mastaler writes:

 > Is it necessary to write a new backend?  Why not just code the unseen
 > sequences functionality into nnmh and optionally, nnml?

Why code the unseen functionality?  Since nnmh isn't quite mh in that
it can't handle asynchronous delivery, there isn't any current code
(AFAIK) which adds messages to nnmh or nnml folders and updates the
unseen sequence.

So, there needs to be another way.  One way would be to have a file
similar to the active file which the mail delivery system writes to;
nnml would only read it and update its own active file based on what
it reads.  The mail delivery system would still have to lock it, but
nnml no longer cares how.

The other way is the method I keep making noises about implementing
but never get my act in gear and implement it.  Let the messages be
delivered directly into nnml folders based on the active file.  Then
keep key headers (for the overview) and add one saying what folder &
nessage number the message was placed at to the normal locked mail
spool.  So now our old trusted mail spool only has headers needed for
overview generation instead of the entire message, and gnus only has
to write active and overview files, not the contents of every message.

(Then all you do is cache the overview lines until group entry instead
of writing them immediately, and writing the unseen handler becomes
easy.)

Either one of these requires both gnus/nnml and the mail deliverer to
back off if it selects a folder's next message number and creating the
file fails, as that means the other just grabbed it.

One of these days...

--Paul