Hi Ken,
If the new struct member is always going to run from 0 without gaps,
I assume so since the current return value is an index into
switches, then it needn't be there?
Well, it doesn't HAVE to be, that's just the way it's implemented now.
Why keep it being an index when it doesn't have to be?
Ah, I assumed the returned index was later used to index, e.g. get the
full-length version of the option for error messages or something. I
agree, if it just needs to be an arbitrary distinct integer, unique for
that array of switches then __LINE__ suffices. :-)
Continue to return the index. Then just have the enum instead of
the #defines to remove the need to maintain the values.
I only think that's marginally easier ... I mean, if I want to know
which enum corresponds to a particular option, I'd have to count it
out by hand, the kind of tedious thing I'd rather leave to a computer.
I do. Move to the first and then 42W in vi to get to the one valued 42.
Also, if I want to rearrange options to make their groupings more
logical (they're kind of a mess right now) I'd have to reorder the
enum list.
True. In that case, do you know the X-macro technique?
http://en.wikipedia.org/wiki/X_Macro
(Though with vim's Ctrl-A in normal, AKA command, mode I don't find
it much of a pain.)
Hrm. AFAICT that just auto-increments the number under the cursor;
how does that help?
I'd have a temporary vim macro created on the fly mapped to `Q' that
incremented the current one and moved to the next.
Cheers, Ralph.
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers