[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Nmh-workers] Future directions for nmh
From: |
Paul Fox |
Subject: |
Re: [Nmh-workers] Future directions for nmh |
Date: |
Sat, 12 Mar 2016 11:05:20 -0500 |
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 back. I've heard that "whatnow" is a Horrible
> Corruption of the MH way, in that everything should be a distinct
> command rather than create a shell that does a bunch of commands. I
> find that argument compelling; any shell we create will lack the full
> power of a command shell, and I'm assuming we don't want to cram all of
> /bin/sh into nmh. So do you (and others) really want a "MIME shell",
> or do you just want a bunch of commands to operate on MIME parts? I
in practice, for me, the shell approach hasn't been an issue. for the
parts of a message that are plain text, or close enough, i can see
them just fine with mhshow, and commandline tools mostly work. for
the non-text parts, the commandline tools don't really work well
anyway -- i'd argue that xv, xpdf or libreoffice, although they all
take a filename as argument, aren't really commandline tools. so
whatever new command we came up with would just invoke one of those
anyway. i just need something, while looking at a message, that will
invoke the right viewer/saver/whatever on a part, without corrupting
it.
i suppose if i wanted to someday go through all of the mail in a
folder and, say, extract all of the pdf attachments from a specific
sender, i'd appreciate a scriptable interface to mime parts, but my
needs so far are met by a per-message interactive process.
paul
> do recognize that there is the issue of command collision, so that's
> one concern. Technically, I see no obvious challenge in doing it as
> individual commands; there would be some file in $(mhdir) that would
> hold current part you're working on, like context today.
>
> If the message parser is done right, mhl would just be a special case of
> your "view" command. Or view would be mhl; details are still a bit
> hazy.
>
> --Ken
>
> _______________________________________________
> Nmh-workers mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/nmh-workers
=----------------------
paul fox, address@hidden (arlington, ma, where it's 47.5 degrees)
- Re: [Nmh-workers] Future directions for nmh, (continued)
Re: [Nmh-workers] Future directions for nmh, Ken Hornstein, 2016/03/11
- Re: [Nmh-workers] Future directions for nmh, Jon Steinhart, 2016/03/11
- Re: [Nmh-workers] Future directions for nmh, Ken Hornstein, 2016/03/12
- Re: [Nmh-workers] Future directions for nmh, Paul Vixie, 2016/03/12
- Re: [Nmh-workers] Future directions for nmh, Paul Fox, 2016/03/12
- Re: [Nmh-workers] Future directions for nmh, Ken Hornstein, 2016/03/12
- Re: [Nmh-workers] Future directions for nmh,
Paul Fox <=
- Re: [Nmh-workers] Future directions for nmh, norm, 2016/03/12
- Re: [Nmh-workers] Future directions for nmh, Paul Vixie, 2016/03/12
Re: [Nmh-workers] Future directions for nmh, norm, 2016/03/12
Re: [Nmh-workers] Future directions for nmh, norm, 2016/03/12
Re: [Nmh-workers] Future directions for nmh, Thomas Levine, 2016/03/16