And I also think that nmh shouldn't have such a low limit on
the number of sequences. Even 59 is, or will soon be, too
low for someone. It'd be nice if we wouldn't have to
reimplement C++ std::vector to get dynamic sizing. Short
of that, I'm with Paul V. on falling back to a bit vector.
Well, let's separate this out into it's component problems:
a) Should there be more than 27 sequences supported? I hope the answer
here is "yes". At least when I pressed the question no one was willing
to say "no". That says to me that people would prefer sequences aren't
silently eaten, but don't want to admit to themselves what the
implications are of that position.
b) What should we do for "new" code when we exceed the per-folder sequence
limit when reading a sequence file?
c) What are the implementation details of sequence storage? Note that this
forces a related question: should there be a hard limit on the number
of per-folder sequences?
I'm a little confused by what you mean when you say you're with Paul V.
regarding bit vectors; Paul said that he didn't think bit vectors were
the right way to represent sequences internally. Okay, fine: what's
your suggestion? In theory anything is possible, but let me bring back
an earlier point: Norm's suggestion is literally a one-line code change.
--Ken
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers