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, pgf@foxharp.boston.ma.us (arlington, ma, where it's 30.0 degrees)
_______________________________________________
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers