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