From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/11398 Path: main.gmane.org!not-for-mail From: Wesley Hardaker Newsgroups: gmane.emacs.gnus.general Subject: Re: TODO idea: Date: 19 Jun 1997 10:47:38 +0200 Organization: Universite de Lausanne, BSP Message-ID: References: NNTP-Posting-Host: coloc-standby.netfonds.no Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII X-Trace: main.gmane.org 1035151112 30000 80.91.224.250 (20 Oct 2002 21:58:32 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 20 Oct 2002 21:58:32 +0000 (UTC) Return-Path: Original-Received: from sandy.calag.com (root@sandy [206.190.83.128]) by altair.xemacs.org (8.8.5/8.8.5) with ESMTP id DAA15424 for ; Thu, 19 Jun 1997 03:55:18 -0700 Original-Received: from xemacs.org (xemacs.cs.uiuc.edu [128.174.252.16]) by sandy.calag.com (8.8.5/8.8.5) with ESMTP id DAA28999 for ; Thu, 19 Jun 1997 03:55:43 -0700 Original-Received: from ifi.uio.no (ifi.uio.no [129.240.64.2]) by xemacs.org (8.8.5/8.8.5) with SMTP id FAA27089 for ; Thu, 19 Jun 1997 05:55:11 -0500 (CDT) Original-Received: from unilmta3.unil.ch (cisun29.unil.ch [130.223.27.29]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id for ; Thu, 19 Jun 1997 10:48:03 +0200 Original-Received: from sphysdec1.unil.ch by unilmta3.unil.ch with SMTP inbound; Thu, 19 Jun 1997 10:47:41 +0200 Original-Received: by sphysdec1.unil.ch (5.65v3.2/Unil-3.1/) id AA22298; Thu, 19 Jun 1997 10:47:39 +0200 Original-To: ding@ifi.uio.no X-Face: #qW^}a%m*T^{A:Cp}$R\"38+d}41-Z}uU8,r%F#c#s:~Nzp0G9](s?,K49KJ]s"*7gvRgA SrAvQc4@/}L7Qc=w{)]ACO\R{LF@S{pXfojjjGg6c;q6{~C}CxC^^&~(F]`1W)%9j/iS/ IM",B1M.?{w8ckLTYD'`|kTr\i\cgY)P4 X-Url: http://www-sphys.unil.ch/~whardake In-Reply-To: Lars Magne Ingebrigtsen's message of 18 Jun 1997 14:09:41 +0200 X-Mailer: Gnus v5.4.50/XEmacs 19.15 Original-Lines: 74 Original-Xref: altair.xemacs.org dgnus-list:1788 Xref: main.gmane.org gmane.emacs.gnus.general:11398 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:11398 >>>>> On 18 Jun 1997 14:09:41 +0200, Lars Magne Ingebrigtsen 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."