Re: [Nmh-workers] nmh internals: argument processing

[Ralph Corderoy]

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.