Re: [Nmh-workers] Relative Message Numbers

[Paul Fox]

ken wrote:
 > Minor nit; your character set was "utf8", but technically it's supposed
 > to be "utf-8" (with the dash).  Ralph also might be getting this wrong,
 > I keep meaning to mention that.  Anyway ...
 > 
 > >in the face of that long-established and well-recognized precedent :-),
 > >how would people feel about this change:
 > >
 > >   The  specification  “name+n”  designates  a  single message, namely the
 > >   `n'th message after `name' (or the last message, if not enough messages
 > >   exist).  One might expect the `n'th message prior to `name' to be spec‐
 > >   ified by “name-n”, but that syntax denotes  a  range.   Therefore,  the
 > >   character  `_'  is used instead:  “name_n” designates the `n'th message
 > >   before `name' (or the first message if not enough messages exist).
 > >
 > >i've implemented the above, to see how it "feels" (which is "okay"). 
 > >i can make the corresponding changes for "foobar+3" and "foobar_2" if
 > >folks think it's reasonable.
 > 
 > Hm.  I'm torn.  So, it looks like it's okay in terms of syntax; "_" is
 > not a valid character in a sequence.  But what are the semantics if
 > “name” refers to more than one message?

yeah, well, i'm having trouble with exactly this point.  what i thought
was obvious when i started implementing is not so obvious after all.

consider:
    $ uip/show first > /dev/null    # set cur to message 1
    $ uip/pick all
    1
    2
    3
    4
    5
    6
    $ uip/pick -sequence foo 1-4
    1
    2
    3
    4

now we notice that the second message is interesting.  there
are several ways to address that message:

    $ uip/pick first+1
    2
    $ uip/pick cur+1
    2
    $ uip/pick foo+1
    1

oops.  this happens because foo is a sequence, and not a message, as
are first and cur.

as ralph pointed out, this feature relies on the user being able to
easily do an on-screen eyeball count to find the message you want in
the list.  introducing a glaring off-by-one issue seems wrong.

the only alternative i can think of is to make the relative counts
for sequences start with '0'.  so instead of the above, you'd have:
    $ uip/pick first+1
    2
    $ uip/pick cur+1
    2
    $ uip/pick foo+1
    2
    $ uip/pick foo+0
    1

note that in this scenario, 'foo+0' is the only way to refer to the
first message in that sequence.  and for completeness, 0 could be
valid in in non-sequence contexts as well:
    $ uip/pick first+0
    1
    $ uip/pick cur+0
    1
    $ uip/pick last~0
    6
    $ uip/pick foo~0
    4


but now that i'm writing this, i think i see that the way out might
simply be to stop using a syntax that looks like arithmetic.  so johan
viklund's suggestion might be right on the money:

 > What about foo#3 and foo#-3? This would mirror the : in sequences,
 > 
 > foo:-3 (three messages from end of foo)
 > foo#-3 (third message from foo's end)

    $ uip/pick first#1
    1
    $ uip/pick first#2
    2
    $ uip/pick cur#1
    1
    $ uip/pick cur#2
    2
    $ uip/pick foo#1
    1
    $ uip/pick foo#2
    2

using a non-arithmetic operator lets us hide what's actually going on
with sequence references.  i haven't thought through this the whole
way, though, so there might still be a surprise.

(and i haven't even begun to think about ralph's extensions to the '#'
syntax.  they hurt my eyes.  ;-)

paul
----------------------
 paul fox, address@hidden (arlington, ma, where it's 53.8 degrees)