* TODO idea: @ 1997-06-06 7:00 Wesley Hardaker 1997-06-06 9:29 ` Lars Balker Rasmussen 1997-06-06 17:36 ` Lars Magne Ingebrigtsen 0 siblings, 2 replies; 35+ messages in thread From: Wesley Hardaker @ 1997-06-06 7:00 UTC (permalink / raw) 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." ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: TODO idea: 1997-06-06 7:00 TODO idea: Wesley Hardaker @ 1997-06-06 9:29 ` Lars Balker Rasmussen 1997-06-06 11:28 ` Kai Grossjohann 1997-06-06 17:36 ` Lars Magne Ingebrigtsen 1 sibling, 1 reply; 35+ messages in thread From: Lars Balker Rasmussen @ 1997-06-06 9:29 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: TODO idea: 1997-06-06 9:29 ` Lars Balker Rasmussen @ 1997-06-06 11:28 ` Kai Grossjohann 0 siblings, 0 replies; 35+ messages in thread From: Kai Grossjohann @ 1997-06-06 11:28 UTC (permalink / raw) Cc: ding >>>>> 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. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: TODO idea: 1997-06-06 7:00 TODO idea: Wesley Hardaker 1997-06-06 9:29 ` Lars Balker Rasmussen @ 1997-06-06 17:36 ` Lars Magne Ingebrigtsen 1997-06-09 8:39 ` Wesley Hardaker 1 sibling, 1 reply; 35+ messages in thread From: Lars Magne Ingebrigtsen @ 1997-06-06 17:36 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: TODO idea: 1997-06-06 17:36 ` Lars Magne Ingebrigtsen @ 1997-06-09 8:39 ` Wesley Hardaker 1997-06-10 2:58 ` Jason R Mastaler 0 siblings, 1 reply; 35+ messages in thread From: Wesley Hardaker @ 1997-06-09 8:39 UTC (permalink / raw) >>>>> 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." ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: TODO idea: 1997-06-09 8:39 ` Wesley Hardaker @ 1997-06-10 2:58 ` Jason R Mastaler 1997-06-10 6:58 ` Wesley Hardaker 1997-06-10 17:52 ` Paul Franklin 0 siblings, 2 replies; 35+ messages in thread From: Jason R Mastaler @ 1997-06-10 2:58 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: TODO idea: 1997-06-10 2:58 ` Jason R Mastaler @ 1997-06-10 6:58 ` Wesley Hardaker 1997-06-11 3:49 ` Jason R Mastaler ` (3 more replies) 1997-06-10 17:52 ` Paul Franklin 1 sibling, 4 replies; 35+ messages in thread From: Wesley Hardaker @ 1997-06-10 6:58 UTC (permalink / raw) >>>>> 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." ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: TODO idea: 1997-06-10 6:58 ` Wesley Hardaker @ 1997-06-11 3:49 ` Jason R Mastaler 1997-06-11 6:49 ` Wesley Hardaker ` (2 more replies) 1997-06-25 8:34 ` anonymous ` (2 subsequent siblings) 3 siblings, 3 replies; 35+ messages in thread From: Jason R Mastaler @ 1997-06-11 3:49 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: TODO idea: 1997-06-11 3:49 ` Jason R Mastaler @ 1997-06-11 6:49 ` Wesley Hardaker 1997-06-16 18:10 ` Paul Graham 1997-06-17 15:33 ` Lars Magne Ingebrigtsen 2 siblings, 0 replies; 35+ messages in thread From: Wesley Hardaker @ 1997-06-11 6:49 UTC (permalink / raw) >>>>> 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." ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: TODO idea: 1997-06-11 3:49 ` Jason R Mastaler 1997-06-11 6:49 ` Wesley Hardaker @ 1997-06-16 18:10 ` Paul Graham 1997-06-17 15:34 ` Lars Magne Ingebrigtsen 1997-06-17 15:33 ` Lars Magne Ingebrigtsen 2 siblings, 1 reply; 35+ messages in thread From: Paul Graham @ 1997-06-16 18:10 UTC (permalink / raw) Cc: ding 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. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: TODO idea: 1997-06-16 18:10 ` Paul Graham @ 1997-06-17 15:34 ` Lars Magne Ingebrigtsen 1997-06-18 6:58 ` Wesley Hardaker 0 siblings, 1 reply; 35+ messages in thread From: Lars Magne Ingebrigtsen @ 1997-06-17 15:34 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: TODO idea: 1997-06-17 15:34 ` Lars Magne Ingebrigtsen @ 1997-06-18 6:58 ` Wesley Hardaker 1997-06-18 12:09 ` Lars Magne Ingebrigtsen 0 siblings, 1 reply; 35+ messages in thread From: Wesley Hardaker @ 1997-06-18 6:58 UTC (permalink / raw) >>>>> 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." ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: TODO idea: 1997-06-18 6:58 ` Wesley Hardaker @ 1997-06-18 12:09 ` Lars Magne Ingebrigtsen 1997-06-18 14:55 ` David S. Goldberg 1997-06-19 8:47 ` Wesley Hardaker 0 siblings, 2 replies; 35+ messages in thread From: Lars Magne Ingebrigtsen @ 1997-06-18 12:09 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: TODO idea: 1997-06-18 12:09 ` Lars Magne Ingebrigtsen @ 1997-06-18 14:55 ` David S. Goldberg 1997-06-19 8:47 ` Wesley Hardaker 1 sibling, 0 replies; 35+ messages in thread From: David S. Goldberg @ 1997-06-18 14:55 UTC (permalink / raw) [-- 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)) ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: TODO idea: 1997-06-18 12:09 ` Lars Magne Ingebrigtsen 1997-06-18 14:55 ` David S. Goldberg @ 1997-06-19 8:47 ` Wesley Hardaker 1997-06-19 17:37 ` Paul Franklin ` (2 more replies) 1 sibling, 3 replies; 35+ messages in thread From: Wesley Hardaker @ 1997-06-19 8:47 UTC (permalink / raw) >>>>> 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." ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: TODO idea: 1997-06-19 8:47 ` Wesley Hardaker @ 1997-06-19 17:37 ` Paul Franklin 1997-06-20 3:58 ` Darren/Torin/Who Ever... 1997-06-19 18:32 ` Scott Blachowicz 1997-06-20 22:12 ` Lars Magne Ingebrigtsen 2 siblings, 1 reply; 35+ messages in thread From: Paul Franklin @ 1997-06-19 17:37 UTC (permalink / raw) >>>>> 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: TODO idea: 1997-06-19 17:37 ` Paul Franklin @ 1997-06-20 3:58 ` Darren/Torin/Who Ever... 0 siblings, 0 replies; 35+ messages in thread From: Darren/Torin/Who Ever... @ 1997-06-20 3:58 UTC (permalink / raw) -----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----- ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: TODO idea: 1997-06-19 8:47 ` Wesley Hardaker 1997-06-19 17:37 ` Paul Franklin @ 1997-06-19 18:32 ` Scott Blachowicz 1997-06-20 9:12 ` Wesley Hardaker 1997-06-20 22:12 ` Lars Magne Ingebrigtsen 2 siblings, 1 reply; 35+ messages in thread From: Scott Blachowicz @ 1997-06-19 18:32 UTC (permalink / raw) Cc: ding 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: TODO idea: 1997-06-19 18:32 ` Scott Blachowicz @ 1997-06-20 9:12 ` Wesley Hardaker 1997-06-20 18:16 ` Scott Blachowicz 0 siblings, 1 reply; 35+ messages in thread From: Wesley Hardaker @ 1997-06-20 9:12 UTC (permalink / raw) >>>>> 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." ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: TODO idea: 1997-06-20 9:12 ` Wesley Hardaker @ 1997-06-20 18:16 ` Scott Blachowicz 1997-06-20 21:32 ` Richard Coleman 0 siblings, 1 reply; 35+ messages in thread From: Scott Blachowicz @ 1997-06-20 18:16 UTC (permalink / raw) Cc: ding >>>>> "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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: TODO idea: 1997-06-20 18:16 ` Scott Blachowicz @ 1997-06-20 21:32 ` Richard Coleman 0 siblings, 0 replies; 35+ messages in thread From: Richard Coleman @ 1997-06-20 21:32 UTC (permalink / raw) Cc: ding > 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: TODO idea: 1997-06-19 8:47 ` Wesley Hardaker 1997-06-19 17:37 ` Paul Franklin 1997-06-19 18:32 ` Scott Blachowicz @ 1997-06-20 22:12 ` Lars Magne Ingebrigtsen 1997-06-21 0:08 ` Richard Coleman 1997-06-22 23:35 ` Darren/Torin/Who Ever... 2 siblings, 2 replies; 35+ messages in thread From: Lars Magne Ingebrigtsen @ 1997-06-20 22:12 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: TODO idea: 1997-06-20 22:12 ` Lars Magne Ingebrigtsen @ 1997-06-21 0:08 ` Richard Coleman 1997-06-21 20:29 ` Scott Blachowicz 1997-06-22 13:32 ` Lars Magne Ingebrigtsen 1997-06-22 23:35 ` Darren/Torin/Who Ever... 1 sibling, 2 replies; 35+ messages in thread From: Richard Coleman @ 1997-06-21 0:08 UTC (permalink / raw) Cc: ding > > 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: TODO idea: 1997-06-21 0:08 ` Richard Coleman @ 1997-06-21 20:29 ` Scott Blachowicz 1997-06-22 13:32 ` Lars Magne Ingebrigtsen 1 sibling, 0 replies; 35+ messages in thread From: Scott Blachowicz @ 1997-06-21 20:29 UTC (permalink / raw) Cc: Lars Magne Ingebrigtsen, ding 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: TODO idea: 1997-06-21 0:08 ` Richard Coleman 1997-06-21 20:29 ` Scott Blachowicz @ 1997-06-22 13:32 ` Lars Magne Ingebrigtsen 1997-06-22 22:24 ` Richard Coleman 1 sibling, 1 reply; 35+ messages in thread From: Lars Magne Ingebrigtsen @ 1997-06-22 13:32 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: TODO idea: 1997-06-22 13:32 ` Lars Magne Ingebrigtsen @ 1997-06-22 22:24 ` Richard Coleman 1997-06-24 21:11 ` Jason R Mastaler 0 siblings, 1 reply; 35+ messages in thread From: Richard Coleman @ 1997-06-22 22:24 UTC (permalink / raw) > > > 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: TODO idea: 1997-06-22 22:24 ` Richard Coleman @ 1997-06-24 21:11 ` Jason R Mastaler 0 siblings, 0 replies; 35+ messages in thread From: Jason R Mastaler @ 1997-06-24 21:11 UTC (permalink / raw) Cc: ding 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. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: TODO idea: 1997-06-20 22:12 ` Lars Magne Ingebrigtsen 1997-06-21 0:08 ` Richard Coleman @ 1997-06-22 23:35 ` Darren/Torin/Who Ever... 1 sibling, 0 replies; 35+ messages in thread From: Darren/Torin/Who Ever... @ 1997-06-22 23:35 UTC (permalink / raw) -----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----- ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: TODO idea: 1997-06-11 3:49 ` Jason R Mastaler 1997-06-11 6:49 ` Wesley Hardaker 1997-06-16 18:10 ` Paul Graham @ 1997-06-17 15:33 ` Lars Magne Ingebrigtsen 2 siblings, 0 replies; 35+ messages in thread From: Lars Magne Ingebrigtsen @ 1997-06-17 15:33 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: TODO idea: 1997-06-10 6:58 ` Wesley Hardaker 1997-06-11 3:49 ` Jason R Mastaler @ 1997-06-25 8:34 ` anonymous 1997-06-25 20:26 ` Paul Franklin 1997-06-26 9:38 ` anonymous [not found] ` <1997 <19970626093841.17915.qmail@sunsite.auc.dk> 3 siblings, 1 reply; 35+ messages in thread From: anonymous @ 1997-06-25 8:34 UTC (permalink / raw) 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-- ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: TODO idea: 1997-06-25 8:34 ` anonymous @ 1997-06-25 20:26 ` Paul Franklin 0 siblings, 0 replies; 35+ messages in thread From: Paul Franklin @ 1997-06-25 20:26 UTC (permalink / raw) >>>>> 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: TODO idea: 1997-06-10 6:58 ` Wesley Hardaker 1997-06-11 3:49 ` Jason R Mastaler 1997-06-25 8:34 ` anonymous @ 1997-06-26 9:38 ` anonymous [not found] ` <1997 <19970626093841.17915.qmail@sunsite.auc.dk> 3 siblings, 0 replies; 35+ messages in thread From: anonymous @ 1997-06-26 9:38 UTC (permalink / raw) 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-- ^ permalink raw reply [flat|nested] 35+ messages in thread
[parent not found: <1997 <19970626093841.17915.qmail@sunsite.auc.dk>]
* Re: TODO idea: [not found] ` <1997 <19970626093841.17915.qmail@sunsite.auc.dk> @ 1997-06-26 19:27 ` Paul Graham 1997-06-26 20:40 ` Paul Franklin 0 siblings, 1 reply; 35+ messages in thread From: Paul Graham @ 1997-06-26 19:27 UTC (permalink / raw) (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. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: TODO idea: 1997-06-26 19:27 ` Paul Graham @ 1997-06-26 20:40 ` Paul Franklin 0 siblings, 0 replies; 35+ messages in thread From: Paul Franklin @ 1997-06-26 20:40 UTC (permalink / raw) >>>>> 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: TODO idea: 1997-06-10 2:58 ` Jason R Mastaler 1997-06-10 6:58 ` Wesley Hardaker @ 1997-06-10 17:52 ` Paul Franklin 1 sibling, 0 replies; 35+ messages in thread From: Paul Franklin @ 1997-06-10 17:52 UTC (permalink / raw) >>>>> 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
end of thread, other threads:[~1997-06-26 20:40 UTC | newest] Thread overview: 35+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1997-06-06 7:00 TODO idea: Wesley Hardaker 1997-06-06 9:29 ` Lars Balker Rasmussen 1997-06-06 11:28 ` Kai Grossjohann 1997-06-06 17:36 ` Lars Magne Ingebrigtsen 1997-06-09 8:39 ` Wesley Hardaker 1997-06-10 2:58 ` Jason R Mastaler 1997-06-10 6:58 ` Wesley Hardaker 1997-06-11 3:49 ` Jason R Mastaler 1997-06-11 6:49 ` Wesley Hardaker 1997-06-16 18:10 ` Paul Graham 1997-06-17 15:34 ` Lars Magne Ingebrigtsen 1997-06-18 6:58 ` Wesley Hardaker 1997-06-18 12:09 ` Lars Magne Ingebrigtsen 1997-06-18 14:55 ` David S. Goldberg 1997-06-19 8:47 ` Wesley Hardaker 1997-06-19 17:37 ` Paul Franklin 1997-06-20 3:58 ` Darren/Torin/Who Ever... 1997-06-19 18:32 ` Scott Blachowicz 1997-06-20 9:12 ` Wesley Hardaker 1997-06-20 18:16 ` Scott Blachowicz 1997-06-20 21:32 ` Richard Coleman 1997-06-20 22:12 ` Lars Magne Ingebrigtsen 1997-06-21 0:08 ` Richard Coleman 1997-06-21 20:29 ` Scott Blachowicz 1997-06-22 13:32 ` Lars Magne Ingebrigtsen 1997-06-22 22:24 ` Richard Coleman 1997-06-24 21:11 ` Jason R Mastaler 1997-06-22 23:35 ` Darren/Torin/Who Ever... 1997-06-17 15:33 ` Lars Magne Ingebrigtsen 1997-06-25 8:34 ` anonymous 1997-06-25 20:26 ` Paul Franklin 1997-06-26 9:38 ` anonymous [not found] ` <1997 <19970626093841.17915.qmail@sunsite.auc.dk> 1997-06-26 19:27 ` Paul Graham 1997-06-26 20:40 ` Paul Franklin 1997-06-10 17:52 ` Paul Franklin
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).