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.
