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

[Ralph Corderoy]

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.

    pick: bad message list all:3

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.

    pick: bad message list all:-3

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.

    pick: bad message list all:+3

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.

    pick: bad message list all=1
    pick: bad message list all=2
    pick: bad message list all=3
    pick: bad message list all=+1
    pick: bad message list all=+2
    pick: bad message list all=+3
    pick: bad message list all=-1
    pick: bad message list all=-2
    pick: bad message list all=-3

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.
https://plus.google.com/+RalphCorderoy