So what exactly are the plans for 2.0?
Here are some things I'd like to see, in increasing order of complexity:
* I'd like to see all the hacky messing with stdio internals taken out in
favour of using the proper APIs. This kind of thing was added as a
performance hack decades ago when MH was run
> So what exactly are the plans for 2.0?
I think the more important question is: Which of the various plans that
people have, need a major effort before the can be released and which
things can drip in as they get done? For the later i think Jon's
approach of "Do whatever you like to see!" is jus
In message <[EMAIL PROTECTED]>, Harald Geyer writes:
>
> > + we should have a new format string escape sequence to add an ASCII
> >representation of the thread tree, so you can make scan display
> >something like this:
> > 441 12/18 Joel Uckelman o [Nmh-workers] mhshow: invalid QUO
> > How about:
> > 441 12/18 Joel Uckelman (0) [Nmh-workers] mhshow: invalid QUO
> > 442 12/18 Josh Bressers (1) Re: [Nmh-workers] mhshow: invalid
> > 443 12/18 Paul Fox (1) Re: [Nmh-workers] mhshow: invalid
> > 444 12/18 Joel Uckelman (2) Re: [Nmh-workers] mhshow: invalid
> > * Threading support. This is one of the obvious things missing from
> > nmh that just about all modern mailers support.
>
> I'm not that sure about this. After all it's about e-mail not usenet.
> I have something like
>
> thread () {
> pick -subject $1 -seq thread
>
One thing I love about ascii-only email is that nmh correctly dumps
the output to the pager for all messages in the sequence selected.
When MIME email gets added to the mix, the user experience changes,
and I have to hit [ENTER] a number of times instead of simply [SPACE]
to view the email. I woul
On 21 December 2005 at 14:08, [EMAIL PROTECTED] wrote:
> So what exactly are the plans for 2.0?
...
> * We really need much better support for MIME
This should include fixing the blind-carbon-copy code to make
message bcc's MIME-compliant. The blind carbon copy has the
really nice (IMO) featu
>Opinions? Anybody else got pet projects they want to share?
I wouldn't mind taking a stab at adding IMAP support to some of the nmh
tools (I guess scan & show are really the important ones; I guess inc
almost becomes a no-op). I think most of the nay-sayers on this one
have died off or gone onto
> > > * Threading support. This is one of the obvious things missing from
> > > nmh that just about all modern mailers support.
> >
> > I'm not that sure about this. After all it's about e-mail not usenet.
> > I have something like
> >
> > thread () {
> > pick -subject $1 -seq th
On 22 December 2005 at 12:10, Paul Fox <[EMAIL PROTECTED]> wrote:
> i want to isolate the thread, and then be able to prev and next
> through it. so i think your method might be okay, if there were
> a "-seq" option to prev and next, which meant "next in sequence".
I'm not following all of this t
> > i want to isolate the thread, and then be able to prev and next
> > through it. so i think your method might be okay, if there were
> > a "-seq" option to prev and next, which meant "next in sequence".
>
> I'm not following all of this threading discussion completely
> (lots of other wo
On 22 December 2005 at 14:15, Paul Fox <[EMAIL PROTECTED]> wrote:
> Previous-Sequence: pseq
>
> which solves my other long-standing annoyance about mh sequences:
> if i do "show unseen" i can't then do "rmm unseen", because, of
> course, they're no longer unseen. but i can now do "rmm pseq"
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Is there any sane way to refile stuff (say a sequence) and specify what
sequence it winds up in on the target folder?
- --
] ON HUMILITY: to err is human. To moo, bovine. | firewalls [
] Michael Richardson,Xelerance Corporati
On 22 December 2005 at 14:45, Michael Richardson <[EMAIL PROTECTED]> wrote:
> Is there any sane way to refile stuff (say a sequence) and specify what
> sequence it winds up in on the target folder?
Here's a halfway answer from refile(1):
If the "Previous-Sequence" profile entry is set, in addi
> but more importantly, there's no way to easily view messages in a
> sequence (like your "thread", above), sequentially, right? if
> not, then simply getting the message numbers of the thread isn't
> all that useful, since i still can't easily read them in order.
>
> i want to isolate the threa
> > well, it doesn't take the "References" or "In-reply-to" headers
> > into account.
>
> No, but most of the time this is not necessary. However sortm -thread
> would be a nice thing. And pick -thread too.
I think pick and sortm are definitely the right place to start with
this. Are you thinkin
> > No, but most of the time this is not necessary. However sortm -thread
> > would be a nice thing. And pick -thread too.
>
> I think pick and sortm are definitely the right place to start with
> this. Are you thinking pick -thread should gather sibling and parent
> threads?
Personally I still
> On 22 December 2005 at 14:45, Michael Richardson <[EMAIL PROTECTED]>
> wrote:
> > Is there any sane way to refile stuff (say a sequence) and specify what
> > sequence it winds up in on the target folder?
>
> Here's a halfway answer from refile(1):
>
>If the "Previous-Sequence" profile entr
--- Chad Walstrom <[EMAIL PROTECTED]> wrote:
> One thing I love about ascii-only email is that nmh correctly dumps
> the output to the pager for all messages in the sequence selected.
> When MIME email gets added to the mix, the user experience changes,
> and I have to hit [ENTER] a number of times
P. Maydell wrote:
> 441 12/18 Joel Uckelman o [Nmh-workers] mhshow: invalid QUO
> 442 12/18 Josh Bressers +oRe: [Nmh-workers] mhshow: invalid
> 443 12/18 Paul Fox +oRe: [Nmh-workers] mhshow: invalid
> 444 12/18 Joel Uckelman |+o Re: [Nmh-workers] mhshow: invalid
> 448 1
>> 441 12/18 Joel Uckelman o [Nmh-workers] mhshow: invalid QUO
>> 442 12/18 Josh Bressers +oRe: [Nmh-workers] mhshow: invalid
>> 443 12/18 Paul Fox +oRe: [Nmh-workers] mhshow: invalid
>> 444 12/18 Joel Uckelman |+o Re: [Nmh-workers] mhshow: invalid
>> 448 12/19 To:nmh-w
Hi Ken,
> You know, I was wondering why I didn't remember the original message
> ... and that was because it was from 7 years ago!
Yes, I was tackling my large backlog of nmh reading and at some point
switched from my recent large backlog to my old large backlog, I too was
confused about the sud
>The OP was talking about thread notation in a scan-style listing. If
>there was a show(1) that let one navigate through a sequence then I
>guess it could display it too.
Oh, someone on that thread posted a link to this:
http://jmason.org/software/scripts/mhthread.txt
Might be worth it for some
On 2012-02-08, at 11:40 AM, Ken Hornstein wrote:
> Since trn is a monolithic application it was easy to integrate it;
> I'm not sure how it would work in nmh.
A separate command that printed a thread connectivity graph as message numbers
might have utility. You could use that as the basis for c
Thus spake Lyndon Nerenberg:
>
> On 2012-02-08, at 11:40 AM, Ken Hornstein wrote:
>
> > Since trn is a monolithic application it was easy to integrate it;
> > I'm not sure how it would work in nmh.
>
> A separate command that printed a thread connectivity graph as message number
> s might have u
ralph wrote:
> Hi Ken,
>
> > You know, I was wondering why I didn't remember the original message
> > ... and that was because it was from 7 years ago!
>
> Yes, I was tackling my large backlog of nmh reading and at some point
> switched from my recent large backlog to my old large backlog
Hi Paul,
> > (My ~/bin/readlp abuses lesskey(1) so little-used keys in less for
> > reading email, e.g. D, do "quit ^@", and this is picked up by the
> > script which then adds it to the "delete" sequence and moves onto
> > the next email to show. N - next, P - previous, S - spam, etc.)
>
>
I want to do IMAP too. I have an idea for design:
1. a .rc file with credentials (i.e. username, password and IMAP server)
2. All mh folders as normal, except if a directory has a ".imaprc" (or
similar) file in it, then it has no real files -- it is a reference
to an IMAP folder
3. Use imapl
On 23 Dec, you wrote:
> I want to do IMAP too. I have an idea for design:
If I had a need for IMAP support, I would sooner consider writing a FUSE
module for an IMAP filesystem. It'd have more chance of working with
scripts written around MH because non-MH commands would work.
Short of a grab on
Is FUSE platform independant? It seems to be fairly Linux-oriented, but
I may not be digging deep enough. This page
http://fuse.sourceforge.net/wiki/index.php/OperatingSystems doesn't seem
to list many OSes yet, but it may be out of date.
From a user perspective, my approach would be invisible
>If I had a need for IMAP support, I would sooner consider writing a FUSE
>module for an IMAP filesystem. It'd have more chance of working with
>scripts written around MH because non-MH commands would work.
>
>Short of a grab only mode in inc I'd be against cluttering all the nmh
>commands with IMA
On Wed, Jan 04, 2006 at 12:56:23AM +1100, Nathan Bailey wrote:
> Of course, the alternative is to write nmh in perl (or python, or ruby,
> ...). This has the benefit of reusing a whole bunch of code that is
> heavily used and maintained (for reading/writing email) and adding only
> the mh-specific
I am doing it -- in fact, I have a perl module that does basic scan,
show, refile and rmm. It also supports hierarchical default mime part
display, i.e. if there is a text/plain part, it shows that, if not, it
shows a text/html part, etc. Finally, it supports mime part viewing,
i.e. I can say
> I want to do IMAP too. I have an idea for design:
> 1. a .rc file with credentials (i.e. username, password and IMAP server)
> 2. All mh folders as normal, except if a directory has a ".imaprc" (or
>similar) file in it, then it has no real files -- it is a reference
>to an IMAP folder
I
I didn't know about .netrc, will check it out.
I can see a whole bunch of empty directories being a waste, but
.mh_sequences does need to be stored somewhere. Perhaps there should
just be a $HOME/[Mail/].imap-mh_sequences that has all of them?
Your syntax idea is a good one, in fact, an URI
> I didn't know about .netrc, will check it out.
>
> I can see a whole bunch of empty directories being a waste, but
> .mh_sequences does need to be stored somewhere. Perhaps there should
> just be a $HOME/[Mail/].imap-mh_sequences that has all of them?
Sequences are a different problem. Since
Nathan, regarding your probe into the IMAP world, we had a bit of a
discussion a few years back about creating an nmh-agent application,
similar to ssh-agent, that would hold persistent IMAP connections and
credentials. nmh applications would need to be made "agent"-aware to
take advantage of this
> > I didn't know about .netrc, will check it out.
Oh, also I forgot to mention that this stuff won't be in the man pages
unless you compiled nmh with POP enabled. It gets seded out if you
don't.
Cheers,
- Joel
___
Nmh-workers mailing list
Nm
> This could be
done with a file on the server, since IMAP allows fairly free form
file retrieval,
Don't count on that. Only uw-imap thinks it's a file server. Most
servers will enforce at least minimal RFC2822 compliance on the data
they serve up, let alone accept via APPEND.
or it c
> >Sequences are a different problem. Since MH has both public and private
> >sequences, I would argue that the only truly "public" sequence for an
> >IMAP folder is one that is stored on the IMAP server. This could be
> >done with a file on the server, since IMAP allows fairly free form
> >file re
>Sequences are a different problem. Since MH has both public and private
>sequences, I would argue that the only truly "public" sequence for an
>IMAP folder is one that is stored on the IMAP server. This could be
>done with a file on the server, since IMAP allows fairly free form
>file retrieval, o
>Of course, it only implements a very small subset of MH functionality,
>but it's enough to access IMAP. And it doesn't do the fundamental (and
>key) operation of refile'ing between IMAP and disk-based folders. I
>also intend to make it exec normal MH commands if it determines the
>folder is
having IMAP folder names be "different" would be a Kosmik Lose(tm)
the only reason to do IMAP would be because it's transparent.
-mo
Joel Reicher wrote:
I want to do IMAP too. I have an idea for design:
1. a .rc file with credentials (i.e. username, password and IMAP server)
2. All mh
> having IMAP folder names be "different" would be a Kosmik Lose(tm)
> the only reason to do IMAP would be because it's transparent.
Every GUI for IMAP that I've ever seen presents the remote folders in
a "section" or "subfolder" representing the IMAP account. This permits
mutiple IMAP accounts an
the GUI is not for "IMAP" - it's a interface for a email UA.
IMAP is but one *implementation* of a folder mechanism,
not something that should be revealed any more than
is strictly necessary. the fact that IMAP might need
collateral metadata to implement the desired abstraction
is a damn nuisanc
45 matches
Mail list logo
