Peter Maydell <pmaydell(_at_)chiark(_dot_)greenend(_dot_)org(_dot_)uk> writes:
Josh Bressers wrote:
It would probably make sense to just give Eric CVS access. Given how lazy
we all are, it's silly to miss these patches.
I don't have any particular objection to giving more people CVS access,
but like Joel I'm not totally sure about whether this should be present.
Yeah, thanks for the vote of confidence, Josh, but I'm not yet
comfortable enough here to commit anything without running it by
the list first anyway.
(I have a script myself which says "list all the folders with unseen
messages", but we can't put every nmh user's scripts into the distribution;
so there has to be a strong consensus that it's filling a definite gap.)
You have one, I have one, lukem has one, Paul Fox has one, Oliver
Kiddle has one, Josh wants one, and I bet Jerry Peek has one :).
I think this is filling a definite gap.
(1) are we happy that 'unseen', 'new', 'fp', 'fn' don't clash with any
other Unix commands? Probably OK, but if anybody has any complaints
about the names they need to be checked now. Perhaps it should be
'fprev' and 'fnext'?
Sure, I don't care about the names; maybe just prefix them with
'mh'? It looks like someone was moving in that direction once
upon a time (mhlist, mhshow, ...).
(2) the new commands need man pages
I can write a simple man page, if this is to be included.
(3) you're assuming the unseen-sequence's name is 'unseen' here:
command = concat ("scan +", node->n_name, " unseen", NULL);
Oops.
(4) you don't seem to handle the profile specifying multiple
unseen sequences
I didn't know this was possible. How does that work?
Unseen-Sequence: unseen foo
or
Unseen-Sequence: unseen
Unseen-Sequence: foo
Does context_find(usequence) return "unseen foo" or what?
(5) your behaviour if no unseen-sequence is specified (assume it's
called "unseen") isn't the same as the rest of nmh, although I'm
not sure what it ought to do instead (fail with an error, maybe)
I don't know where I got the notion of "unseen" as a default;
maybe from the original 'new', or maybve ex recto. Anyway, I can
make it error out.
(6) I'm a bit dubious about the use of system() to run scan; it
feels to me like if you're a core part of nmh you should just
be able to call a function to do the scan output directly.
Sure, but there is no function like scan(char *folder, char
*msg_spec), and breaking this out of uip/scan.c is a task for
another day (and probably for someone else :) (but see below).
Also, where does the '.folders' file come from? I seem to have one,
but it only has a few of my folders listed in it...
folders -fast -recur > .folders
Keeping that file sorted as you prefer is up to you :). My inc
script updates it as it creates new folders, and has a
configurable sort. As another example, Paul Fox says he has a
similar script which keeps a sort order and excludes some folders
and therefore he can't use this, but he could have it store that
order in .folders instead.
[Technically that call to concat() ought to end in "(char*)NULL"
or "(char*)0" but none of the rest of nmh seems to get that bit
of C trivia right either :-)]
Are you sure? All pointers are the same size, regardless of the
size of the data they point to, and there is no type checking on
a variadic function. So, why the cast?
Oliver Kiddle <okiddle(_at_)yahoo(_dot_)co(_dot_)uk> writes:
I hate to be negative but my main objection to these commands is that
they are hardcoded to the unseen sequence instead of being more general.
Hmm, I guess it's easy enough to adapt it to take a sequence
argument, or arguments, as it needs to handle multiple unseen
sequences anyway.
* -- as fn, move to next folder with unseen messages
* -- as fp, move to previous folder with unseen messages
* -- as unseen, scan all unseen messages
Which is just a multi-folder scan. It might be better to adapt scan so
that you can specify multiple folders with a sequence.
Not quite; 'scan $(cat $(mhpath +)/.folders) unseen' isn't as
nice as just 'unseen'.
For the record: I've never used 'unseen'; I just implemented for
feature parity with the original. Especially if we change the
names, I'm fine with dropping it entirely. This would also
address Peter's concern about system(scan).
Thanks.
--
Eric Gillespie <*> epg(_at_)pretzelnet(_dot_)org
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
http://lists.nongnu.org/mailman/listinfo/nmh-workers