Re: Future directions for nmh

Wow, have I been away since 2016? Assuming it's no longer moot, I have a couple of thoughts regarding grepable mail: 1. I use grep via MH-E probably on a weekly basis to find messages in non-indexed folders. 2. I also use grep to discover deleted messages more often than I'd like to

Re: [Nmh-workers] Future directions for nmh

>But this makes it *your* turn to come up with an insane idea. > >Waiting ... Well ... okay! So, honest critique time: you know more about IMAP than I do. If you see problems with this, please let me know what they are. I'm speaking in terms of existing nmh interfaces; presumably they would

Re: [Nmh-workers] Future directions for nmh

> On Mar 16, 2016, at 6:04 PM, Paul Vixie wrote: > > prayer is the simplest and faster webmail system i ever found for my family's > use while traveling. But. How. Does webmail have anything to do with this? ___ Nmh-workers

Re: [Nmh-workers] Future directions for nmh

Lyndon Nerenberg wrote: On Mar 16, 2016, at 6:04 PM, Paul Vixie wrote: prayer is the simplest and faster webmail system i ever found for my family's use while traveling. But. How. Does webmail have anything to do with this? webmail and mh both have a fork+exec before

Re: [Nmh-workers] Future directions for nmh

Ken> export MHCONTEXT context-$$ .. I live and learn, thanks. Ken> in the above scenario, what do you EXPECT nmh to do? Well, from experience, I expect it to do what I tell it, even if that's not what I intend :-/ My preference would be for actions (rmm, refile, repl) to note there's been a

Re: [Nmh-workers] Future directions for nmh

Ken> You run command (a) which changes the context. How is command (b) Ken> supposed to know that the context has been changed? Given your mentioning of MHCONTEXT, I could envisage a wrapper for MH commands much like Paul Fox's example — perhaps a context directory containing per-shell-PID

Re: [Nmh-workers] Future directions for nmh

Ken> it makes it WORSE; each nmh command starts with a brand-new scan of a Ken> folder, so messages added or removed between commands work out fine. Ken> But a FUSE interface would have no idea when an nmh command is starting Ken> or stopping, so you'd have to do a lot of caching or a new IMAP

Re: [Nmh-workers] Future directions for nmh

The context issue (and a related client issue) is actually why I stopped using mh a while back. I switched professions and needed the email client on my phone to interact reasonably with the client on my laptop (or server typically accessed via laptop). For a while, I ssh’d into a server and

Re: [Nmh-workers] Future directions for nmh

On 09 Mar 10:18, Ken Hornstein wrote: > 4) In terms of alternate mail stores, be they Maildir or IMAP (I think >those are the two major candidates now, right?), I think those ideas >are interesting. The #1 problem with those ideas is how to map MH >message numbers (which can range

Re: [Nmh-workers] Future directions for nmh

Lyndon Nerenberg wrote: On Mar 16, 2016, at 4:56 PM, Ken Hornstein wrote: And I believe it makes it WORSE; each nmh command starts with a brand-new scan of a folder, so messages added or removed between commands work out fine. But a FUSE interface would have no idea when an

Re: [Nmh-workers] Future directions for nmh

Hi Paul, > most invocations of my wrapper commands record their parent's pid in a > well-known file. the wrapper for rmm, when not given a specific > argument (i.e., "d", rather than "d 32") checks to make sure its > parent's pid is the same as what's recorded in the file Nice idea. Cheers,

Re: [Nmh-workers] Future directions for nmh

Conrad Hughes wrote: Ken> it makes it WORSE; each nmh command starts with a brand-new scan of a Ken> folder, so messages added or removed between commands work out fine. Ken> But a FUSE interface would have no idea when an nmh command is starting Ken> or stopping, so you'd have to do a lot

Re: [Nmh-workers] Future directions for nmh

>You know this sort of thing falls well outside POSIX. It would be inside >a non-portability #ifdef. Heh, well, I just wanted to remind you of your previous opinions, that's all :-) >Actually, that's my preferred scheme. But it's not trivial to do – on >either side – so FUSE seemed like a more

Re: [Nmh-workers] Future directions for nmh

> On Mar 11, 2016, at 9:09 PM, Ken Hornstein wrote: > > I was under the impression that your view > of an IMAP mailbox at least in terms of message numbers is fixed during > a single IMAP session. I know messages can be added or removed from > a mailbox and you're get notified

Re: [Nmh-workers] Future directions for nmh

>if MH could proxy its IMAP operations through a daemon running on a unix >domain socket or the loopback interface, then we could idealize the RPC >API between MH and that daemon. one thought is restful json. I'm fine with that idea as well (although I see some issues in terms of

Re: [Nmh-workers] Future directions for nmh

conrad wrote: > Ken> export MHCONTEXT context-$$ > > .. I live and learn, thanks. > > Ken> in the above scenario, what do you EXPECT nmh to do? > > Well, from experience, I expect it to do what I tell it, even if that's > not what I intend :-/ > > My preference would be for actions

Re: [Nmh-workers] Future directions for nmh

>Given your mentioning of MHCONTEXT, I could envisage a wrapper for MH >commands much like Paul Fox's example — perhaps a context directory >containing per-shell-PID context files, and the crucial test would be >whether another context file was more recent than and different to this >shell's one

Re: [Nmh-workers] Future directions for nmh

>My preference would be for actions (rmm, refile, repl) to note there's >been a context change and ask for confirmation, I think. The machine is >better than I am at tracking consistency. If context-in-this-window and >most-recent-context are different (or more particularly, the action >target

Re: [Nmh-workers] Future directions for nmh

> On Mar 16, 2016, at 4:56 PM, Ken Hornstein wrote: > > And I believe > it makes it WORSE; each nmh command starts with a brand-new scan of a > folder, so messages added or removed between commands work out fine. > But a FUSE interface would have no idea when an nmh command is

Re: [Nmh-workers] Future directions for nmh

> IMAP has a somewhat bizarre idea of the transactional state of a mailbox, > primarily in reference to deleted messages and preserving message reference > views across multiple client connections Sorry, I meant to say 'preserving message sequence views'.

Re: [Nmh-workers] Future directions for nmh

>Arguably this is a problem already: all the time I have to keep in my >head that I must be careful about changing nmh state among my (usual) >four terminal windows: I'm reading one email in one folder, see >something arrive in another folder, look at that in another window, go >back to the first

Re: [Nmh-workers] Future directions for nmh

> On Mar 16, 2016, at 4:56 PM, Ken Hornstein wrote: > > But here's the thing I really want to get at. People bring up FUSE > as a viable interface for nmh to use for IMAP. The point I'm trying > to make is: as far as I can tell, a FUSE interface to IMAP does _not_ > solve the

Re: [Nmh-workers] Future directions for nmh

Ken Hornstein wrote: i don't know exactly how to match mime to the simplicity of show(1), and i've been violently repulsed any time i tried to use mhshow(1), but i I can't really blame you on that one. But really, mhshow(1) is really just the old mhn, slightly rewritten. And mhn was a

Re: [Nmh-workers] Future directions for nmh

n...@dad.org writes: Correction: >Hear, Hear. But I assume and hope that you are talking about new commands >rather than more arguments to additional commands. I meant: Hear, Hear. But I assume and hope that you are talking about new commands rather than more arguments to existing commands.

Re: [Nmh-workers] Future directions for nmh

Ken Hornstein writes: >But I have to ask about the idea of going from one MIME part to another; >do you really want to do that? I can only go on how I interact with >messages; almost always, I want to read the text part, and then interact >in some other way with non-text parts

Re: [Nmh-workers] Future directions for nmh

ken wrote: > Alright, I see where you're going with this. Fair enough; that's not > how I personally work with MIME messages, but enough people have said > that they want this (and Paul even wrote something that does it!) that > clearly this UI fills a need. > > But ... let's take a step

Re: [Nmh-workers] Future directions for nmh

>i don't know exactly how to match mime to the simplicity of show(1), and >i've been violently repulsed any time i tried to use mhshow(1), but i I can't really blame you on that one. But really, mhshow(1) is really just the old mhn, slightly rewritten. And mhn was a horrible hack, we all

Re: [Nmh-workers] Future directions for nmh

Laura wrote: > but I would be seriously inconvenienced if mh directory mail store > went away. Enough of us would also, I expect, that this won't happen. At least at some layer that the user can see. David ___ Nmh-workers mailing list

Re: [Nmh-workers] Future directions for nmh

paul vixie wrote: > Ken Hornstein wrote: > >> Well, it depends on the message. Sometimes I get a message with 20 photos > >> attached. I just want to be able to easily go from one to the next > >> without > >> having to type their part number. > > > > But ... what's wrong with doing

Re: [Nmh-workers] Future directions for nmh

Ken Hornstein wrote: Well, it depends on the message. Sometimes I get a message with 20 photos attached. I just want to be able to easily go from one to the next without having to type their part number. But ... what's wrong with doing something like: mhstore -type image Then you can

Re: [Nmh-workers] Future directions for nmh

>Well, it depends on the message. Sometimes I get a message with 20 photos >attached. I just want to be able to easily go from one to the next without >having to type their part number. But ... what's wrong with doing something like: mhstore -type image Then you can deal with each of those

Re: [Nmh-workers] Future directions for nmh

>Rather than push the mailstore code into MH, I think a much cleaner >model would be to use FUSE-based providers that translate between >external store formats and the native MH layout. This means no >intrusive changes to MH itself, and people can roll whatever >translators they want. There was

Re: [Nmh-workers] Future directions for nmh

> On Mar 11, 2016, at 11:01 AM, Paul Vixie wrote: > > my situation is the opposite. i'd like multiple mail store types inside NMH, > or a pluggable hooks-style interface allowing the creation of same, so that i > can use NMH command line tools to attack my Maildir store as

Re: [Nmh-workers] Future directions for nmh

Ken Hornstein writes: > >As you might guess if you've been on this mailing list forever, I'd > >really like to see a better user interface for reading attachments. > >In short, I'd like to keep track of the "current part", and have > >"next part" and "previous part" options to show. There should

Re: [Nmh-workers] Future directions for nmh

>As you might guess if you've been on this mailing list forever, I'd >really like to see a better user interface for reading attachments. >In short, I'd like to keep track of the "current part", and have >"next part" and "previous part" options to show. There should be >a flag that allows

Re: [Nmh-workers] Future directions for nmh

I'd just like to mention that I am still getting lots of use out of the mh mail storage. A lot of the mail that I receive is code checkins. Perhaps when everybody on the planet has moved all of their code to github (as seems to be happening whenever I turn around) I won't need my tools to find

Re: [Nmh-workers] Future directions for nmh

Ken Hornstein wrote: i believe that the gnu team has an MH-like tool set that's designed this way. if so then we might just tell people like me to go use that. If you're talking about GNU mailutils, then yes. I mean, it does include a MH-compatibility layer and works with IMAP; I do not

Re: [Nmh-workers] Future directions for nmh

>i believe that the gnu team has an MH-like tool set that's designed this >way. if so then we might just tell people like me to go use that. If you're talking about GNU mailutils, then yes. I mean, it does include a MH-compatibility layer and works with IMAP; I do not know how full-featured it

Re: [Nmh-workers] Future directions for nmh

Jon Steinhart wrote: OK. That's a really cool idea. One could even contemplate using gmail as a mail store to make it easier for the NSA to read your mail. Maybe the hooks should be replaced by one of the DLLs. This sounds like a huge change in the codebase, so hopefully someone is up for

Re: [Nmh-workers] Future directions for nmh

Ken Hornstein writes: > >All of the email about which I care has ASCII subject lines. > >Also, I often grep for a particular attachment name. > > Right or wrong, I get subject lines that are encoded using RFC 2047 > rules. I know you think of those as 'foreign languages', but that is > wrong;

Re: [Nmh-workers] Future directions for nmh

>OK. That's a really cool idea. One could even contemplate using gmail as a >mail store to make it easier for the NSA to read your mail. Maybe the hooks >should be replaced by one of the DLLs. This sounds like a huge change in >the codebase, so hopefully someone is up for it. Being

Re: [Nmh-workers] Future directions for nmh

Paul Vixie writes: > > Jon Steinhart wrote: > > ... > > Are you saying that you'd like to see the nmh cli abstracted to the point > > where it could work on different flavors of mail store? If so, that seems > > like a big change. Sort of like the hooks, but with a DLL interface > > instead of

Re: [Nmh-workers] Future directions for nmh

Jon Steinhart wrote: ... Are you saying that you'd like to see the nmh cli abstracted to the point where it could work on different flavors of mail store? If so, that seems like a big change. Sort of like the hooks, but with a DLL interface instead of the shell? yes. -- P Vixie

Re: [Nmh-workers] Future directions for nmh

>All of the email about which I care has ASCII subject lines. >Also, I often grep for a particular attachment name. Right or wrong, I get subject lines that are encoded using RFC 2047 rules. I know you think of those as 'foreign languages', but that is wrong; they are just 'characters'. Also,

Re: [Nmh-workers] Future directions for nmh

Paul Vixie writes: > Jon Steinhart wrote: > > ... > > I think that we should keep the mail store as is. I agree that the MIME > > and character set stuff has made it less grep-able than it used to be, > > but it's still useful. > > useful for what? i have no remaining use cases of my own. All

Re: [Nmh-workers] Future directions for nmh

Jon Steinhart wrote: ... I think that we should keep the mail store as is. I agree that the MIME and character set stuff has made it less grep-able than it used to be, but it's still useful. useful for what? i have no remaining use cases of my own. I am emboldened by David's posting

Re: [Nmh-workers] Future directions for nmh

Howdy. I want to start by thanking those of you who actually have time to work on this. Wish that I had some time to spare. Here's my grumpy-don't-break-things opinion. I support redoing the email parser and making everything MIME-aware. As you might guess if you've been on this mailing list

Re: [Nmh-workers] Future directions for nmh

Andy Bradford wrote: What's wrong with the way nmh does it today? Maildir is certainly superior for some of the reasons detailed below, but nmh's Mail store isn't very far off: http://cr.yp.to/proto/maildir.html some of us have converted to Maildir, but we miss MH's CLI

Re: [Nmh-workers] Future directions for nmh

Thus said Ken Hornstein on Wed, 09 Mar 2016 10:44:55 -0500: > I am saying that we have people who want to use the nmh tools with > both IMAP and Maildir mailstores. So making the nmh tools work with > those mailstores would be useful. Oh, I misunderstood. So part of my last email is no

Re: [Nmh-workers] Future directions for nmh

Thus said Ken Hornstein on Wed, 09 Mar 2016 10:18:04 -0500: > 1) I do not think converting and storing incoming messages as UTF-8 is >wise. In terms of just simplicity alone I think messages should be >stored (somewhere) in their on-the-wire format; I too agree with this position. The

Re: [Nmh-workers] Future directions for nmh

Ken> I am saying that we have people who want to use the nmh tools with both Ken> IMAP and Maildir mailstores. So making the nmh tools work with those Ken> mailstores would be useful. .. with migration via refile between different store types .. that sounds cool.. C.

Re: [Nmh-workers] Future directions for nmh

>>4) In terms of alternate mail stores, be they Maildir or IMAP (I think >>those are the two major candidates now, right?), I think those ideas >>are interesting. The #1 problem with those ideas is how to map MH >>message numbers (which can range 1-MAXINT, with holes) to the internal >>key used

Re: [Nmh-workers] Future directions for nmh

Ken Hornstein writes: > >4) In terms of alternate mail stores, be they Maildir or IMAP (I think >those are the two major candidates now, right?), I think those ideas >are interesting. The #1 problem with those ideas is how to map MH >message numbers (which can range 1-MAXINT,

[Nmh-workers] Future directions for nmh

So, since my simple question about a new release spawned a whole thread about the future direction of nmh I wanted to create a distinct thread to discuess those ideas. If you're interested in commenting on future ideas for nmh, this is the place to do it. I am first going on the assumption that