nmh-workers
[Top][All Lists]

## [Nmh-workers] One-based {reserved, userseq}{:, =}{, -, +}N mh-sequence(5

 From: Ralph Corderoy Subject: [Nmh-workers] One-based {reserved, userseq}{:, =}{, -, +}N mh-sequence(5). Date: Sun, 03 Sep 2017 15:37:04 +0100

```Hi,

I've a packed folder with nine emails and a user sequence called `mid'
for middle.  Using pick(1) and tr(1) I blot out those that aren't picked
with `.'s.  Here are the results, along with my comments.  `R' stands
for a `reserved message name', and `U' for a user sequence.

all  123456789
cur  ....5....
mid  ..34567..

OK.

cur:3  ....567..
next:3  .....678.
first:3  123......

These match mh-sequence(5): R:N is N starting with R.

mid:3  ..345....

Matches mh-sequence(5): U:N is first N of U.

prev:3  .234.....
last:3  ......789

Matches.  R:N is N ending with R.  Opposite to the others because prev
and last are "backwards" in meaning.

First problem, all is special compared to the user sequence mid.  I'd
expect the same as first:3.

cur:-3  ..345....
next:-3  ...456...
prev:-3  .234.....
last:-3  ......789

R:-N is N ending with R.  For prev and last, R:-N is the same as R:N.

first:-3  1........

3 ending on first would be -1, 0, 1, so we've just 1.  But it's a bit
odd looking.  So first:-N is first for all N.  Should this be an error?

mid:-3  ....567..

For a user sequence, U:-N is the last N of U.

If it was the same as `last:-3' then `all:N' could be used when N is 3
or -3 without having to switch between first and last.

cur:+3  ....567..
next:+3  .....678.
first:+3  123......
prev:+3  ...456...

`R:+N' is N starting at R.  For cur, next, and first, R:+N is the same
as R:N.

last:+3  ........9

`last:+N' is last for all N.  Error?

mid:+3  ..345....

`U:+N' is the first N of U.

Not like `first:+3' that's AKA `first:3'.

cur=1  ....5....
cur=2  .....6...
cur=3  ......7..
cur=+1  ....5....
cur=+2  .....6...
cur=+3  ......7..
cur=-1  ....5....
cur=-2  ...4.....
cur=-3  ..3......

R=N, R=+N, and R=-N are one-based offsets from R.  I find that a bit odd
in use, having to think about the number to use because I expect cur:0
to be cur, cur:1 to be next, and cur:-1 to be prev, IOW an offset.  N
being 0 is currently an error.  And this matters because cur is handily
also `.', so .=2 would be a simple way to say two forwards, but I have
to think third instead and .=3.

next=1  .....6...
next=2  ......7..
next=3  .......8.
next=+1  .....6...
next=+2  ......7..
next=+3  .......8.
next=-1  .....6...
next=-2  ....5....
next=-3  ...4.....

As with cur, so with next.

prev=1  ...4.....
prev=2  ..3......
prev=3  .2.......
prev=+1  ...4.....
prev=+2  ....5....
prev=+3  .....6...
prev=-1  ...4.....
prev=-2  ..3......
prev=-3  .2.......

The "backwards" nature of prev comes into play here.  Unsigned N is
treated as -N whereas mathematically we're used to reading it as the
same as +N.  A bit confusing.

first=1  1........
first=2  .2.......
first=3  ..3......
first=+1  1........
first=+2  .2.......
first=+3  ..3......
first=-1  1........
pick: no such message [first=-2]
pick: no such message [first=-3]

OK when N is unsigned or positive.  first=-1 is OK.  first:-3 ignored
that -1 and 0 didn't exist, but here's it's an error.  I'm not trying to
show the message, just use pick to intersect, etc., so an empty set
would seem OK too?

last=1  ........9
last=2  .......8.
last=3  ......7..
last=+1  ........9
pick: no such message [last=+2]
pick: no such message [last=+3]
last=-1  ........9
last=-2  .......8.
last=-3  ......7..

last suffers from both prev's backwardness meaning unsigned N is
negative, and first's lack of ignoring out of bounds.

mid=1  ..3......
mid=2  ...4.....
mid=3  ....5....
mid=+1  ..3......
mid=+2  ...4.....
mid=+3  ....5....
mid=-1  ......7..
mid=-2  .....6...
mid=-3  ....5....

Again, for a user sequence rather than a reserved message name, the same
syntax has a different meaning.  U=N and U=+N is U's Nth message, and
U=-N is U's Nth-last message.  I think we're more used to seeing U=0 as
this message, U=1 as the next, and U=-1 as its last, a la Python's
indexing, and other languages.

Uh-huh.

So there's a lot of overlap with distinct phrases meaning the same
thing, e.g. the `+' sometimes does nothing, sometimes it's the `-'.
It's one-based when most of us are probably used to using zero-based,
i.e. offsets, elsewhere.  And it's inconsistent over whether out of
bounds are ignored or an error.

Lastly, shouldn't mh-sequence(5) be (7) since the file format is such a
minor part, and could still be in (5)?

--
Cheers, Ralph.