Hi Paul,
$ mark -list 2-6 <-- previously behaved as "mark -list", above
odd: 3 5
even: 2 4 6
I would have expected an extra line,
$ mark -list 2-6
+ cur:
odd: 3 5
even: 2 4 6
because the messages given are being intersected with the normal
‘mark -list’ output you showed at the start above.
The current behavior matches my requirements, and the (new)
description in the man page describes it.
Naturally. :-)
I wasn't thinking of it as an intersection, but a membership listing:
"If msgs are specified, then only the sequence memberships for the
given messages are shown, either for all sequences, or just for
those named by -sequence switches."
IOW, if no messages are given then the default is ‘all’. This seems
more orthogonal to me and means a script can give multiple sequences
and expect one line for each in the output in the order the
sequences were stated; there's no need to parse the ‘foo:’ or ‘bar
(private):’ to identify the sequence involved.
I understand your need. How about if adding "-zero" caused sequences
in which the named messages aren't members to be listed as well?
I.e., "include sequences with 'zero' results", The -zero switch is
already overused by delete (to mean, "invert"), so I don't think this
is too big a leap. New (additional) man description:
"Normally sequences in which none of the given msgs are members are
suppressed in the output. The -zero switch will cause all
sequences mentioned on the command line to be listed, whether or
not they include any of the specified messages."
My suggested behaviour:
- Using -list shows sequences and the messages in them.
- If any -sequences are given then only those sequences are listed
rather than all sequences.
- If any messages are given then only those messages will be shown
rather than all messages.
I don't need to describe the interaction of those two cases because they
combine in the natural manner; they're orthogonal to each other.
(The code may well echo that lack of intertwining.)
You're suggesting not listing sequences with zero messages. The
existing -zero/-nozero option's default is -nozero but mark's existing
behaviour is to list sequences with zero messages so the meaning doesn't
match. (And the overloading of -zero for -delete's use has always
seemed confusing and non-obvious to me. :-)
A new -empty/-noempty could state whether to list empty sequences.
Default -empty to keep the existing behaviour.
An example not given here would be empty sequences, i.e. ones which
don't exist. Currently:
$ mark -l -s cur -s foo -s bar -s xyzzy
cur: 96894
foo:
bar: 97036
xyzzy:
Is this actually the desired behavior? Shouldn't mark instead complain
with "mark: no such sequence as xyzzy"?
That would be annoying if I want to know which sequences are empty.
Would mark(1) state that on stderr and stop or keep going on stdout for
non-empty sequences? Does stderr get just the first one which doesn't
exist, or all of them? Just the first means a script would have to
adjust and re-run until stderr is empty as well as capturing both stdout
and stderr.
(It's an annoying artefact of MH's implementation that an empty sequence
is deleted and thus indistinguishable from a typo'd sequence. It's like
not having the number zero.)
I hadn't realized that mark was currently silent about this, and my
patch is not silent like that, when messages are provided:
$ mark -l -s odd -s xyzzy
odd: 1 3 5 7 9
xyzzy:
$ mark -l -s odd -s xyzzy 1
odd: 1
mark: no such sequence as xyzzy
The behaviors should clearly match.
Yes.
I think I'd prefer the error, but you can try to convince me..
You'd be changing existing behaviour.
> BTW, ‘first’, etc., aren't sequences, as we know.
>
> $ p -seq first 42
> pick: sequence name is reserved: first
>
> Yet,
>
> $ mark -l -s first -s cur -s last -s foo -s bar -s xyzzy
> first:
> cur: 96894
> last:
> foo:
> bar: 97036
> xyzzy:
> $
>
> mark(1) doesn't complain and I'd expect it to as pick does.
I agree that it should be an error. And again, it seems that if
"first" is in error, then "xyzzy" should also be considered an error.
I don't think so because ‘first’ is a reserved word, as the error says,
whereas ‘xyzzy’ isn't. (Though surely we can think of some meaning and
make is so. :-)
--
Cheers, Ralph.