nmh-workers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nmh-workers] Relative Message Numbers


From: Paul Fox
Subject: Re: [Nmh-workers] Relative Message Numbers
Date: Tue, 02 Apr 2013 09:13:15 -0400

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 ...

fixed, i think.

 > 
 > >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.

understandably.  it's butt-ugly -- no one should love it.

 > 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?

i think that can only mean user-defined sequences, right?  (ignoring
"all" for now.)

semantics will be similar to those of foo:3, foo:-3, etc.   foo+3 will
be the 3rd message in foo, foo_3 will be the 3rd message from the end
of foo.  but in foo:3, 3 is a count, whereas in foo+3, i'm assuming 3 is
an index, presumably starting at '1'.  you raise a good point.

it's worth spelling it all out:

given:
    $ pick -sequence foobar 269-279
    $ show 270 > /dev/null
    $ pick foobar
    269
    270                 <--- cur
    274
    276
    277
    279

    $ pick cur              # current behavior
    270

the semantics for ':n' say that n is a count of messages, i.e., we're
asking for "two messages starting at cur":

    $ pick cur:2            # current behavior
    270
    274
    $ pick cur:-2           # current behavior
    269
    270

for sequences, ':n' refers to the n messages at the start/end of seq
    $ pick foobar:2         # current behavior
    269
    270
    $ pick foobar:-2        # current behavior
    277
    279


for +/_, i think the desired behavior is "second message from cur"
    $ pick cur+2            # proposed behavior.  compare with cur:2
    276
    $ pick cur_2            # proposed behavior.  compare with cur:-2
    268

and for sequences, "nth message from start/end of sequence"
    $ pick foobar+2         # proposed behavior.  compare with foobar:2
    270
    $ pick foobar_2
    277

you can see that the switch from n being a count of messages to
being an index into the list has interesting semantic effects, but
i don't think they're very surprising.

norm wrote:
 > If name has fewer than n messages then I would prefer an abort with
 > error message.  Paul Fox would, I gather, prefer a semantics where
 > name+n and name_n are always meaningful.

actually, i don't have a strong opinion on this, and was mainly following
existing practice, in that neither "cur:n" nor "foobar:n" will error
out if 'n' goes into non-message territory.

    $ pick foobar:20        # current behavior, no error
    269
    270
    274
    276
    277
    279

but perhaps the +/_ versions should cause an error.

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]