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] mhfixmsg defies the principle of last surprise?

On Thu, 17 Mar 2016 11:38:01 -0400, David Levine said: > Valdis wrote: > > > So trying to debug why a message got eaten by procmail. > > What does "mhlist -file t1" say about the message? mhfixmsg -verbose? > > Would you please send me some reasonably complete extract of the message so > that I

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] mhfixmsg defies the principle of last surprise?

Valdis wrote: > Sending you the message as an attachment via private e-mail. The MIME boundaries didn't match, and the one at the end of the message was broken across two lines. mhlist did notice. I committed a fix to mhfixmsg to not modify the message. At all. Thanks. David

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] mhfixmsg defies the principle of last surprise?

Valdis wrote: > So trying to debug why a message got eaten by procmail. What does "mhlist -file t1" say about the message? mhfixmsg -verbose? Would you please send me some reasonably complete extract of the message so that I can debug it? David

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