>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
be
> 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 mailing list
Nmh-workers
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 every operation, thu
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 con
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 contex
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 sess
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 ran
> On Mar 11, 2016, at 9:09 PM, Ken Hornstein wrote:
>
> There was a guy on this mailing list who's name escapes me right now ...
> who was a real bear when it came to insisting that nmh should stick to
> 100% POSIX compatibility. You should talk to him. What was his name
> again ?
Oh bite
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 1-MA
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 nmh command is sta
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, Ral
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
>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 p
> 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 in the middle of
>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
authentication,
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 (r
>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 wh
>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 (c
> 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 starting
> or stop
> 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'.
__
>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 w
> 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 above problem; yo
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 horri
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.
Ken Hornstein writes:
>>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 h
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 (generally save the
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 ba
>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 agree
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
Nmh-workers@no
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 somet
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 deal
>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 pho
>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 a
> 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 created for me
> by
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 b
>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 switchin
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 out
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 know
>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 i
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 i
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; the
>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 geezer-ish,
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 t
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
__
>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, if
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 of
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 regard
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 f
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 capability.
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 lon
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 e
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.
___
>>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 by
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, with holes) to the
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 c
55 matches
Mail list logo