On Mon, 12 Feb 2018 09:27:04 +0000 Ralph Corderoy <ra...@inputplus.co.uk> wrote:
Ralph Corderoy writes:
> Hi Paul,
> > i just don't know whether MH can attract new users through a rewrite.
> That wouldn't be the aim. The aim would be for the existing users to
> have a code base that allowed more rapid, stable development of new
> features, deprecating old warts, and improving consistency.
> For example, whilst I like the Unix idiom of one command to do one thing
> well, I do find myself doing a series of picks, marks, and scans to
> whittle down emails whereas having a consistent, planned, notation that
> can be used wherever a message number can be given would lessen the
> iterations a lot. `seq=-3' is nice, but I can't do `seq:-3:2', for
> example. And overall it's warty, so warty no one replied to my
I don't remember your message but I did look at message
sequence number selection in some detail when I was
implementing it in Go. My initial implemention just treated it
as simple number sequences independent of context but messages
that match a selection expession depend on which messages
exist. As an example, if you have messages 1 2 5 8 in a
mailbox, Thus 5:3 match es 5 & 8. And the start message need
not exist. 10:-2 matchs 5 & 8 but 10:1 fails. The semantics
are fairly consistent. Except for last! last:2 matches 5 & 8
but 8:2 matches only 8. But last is a small anomaly.
I can see extending it so that an expressions as seq:-3:2
(which would be equivalent to seq=-3:2) works but given the
context sensitivity, I think it would be rather confusing.
But I admit I have often wanted next:n or prev:n.