[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Nmh-workers] nmh internals: argument processing
From: |
Ken Hornstein |
Subject: |
Re: [Nmh-workers] nmh internals: argument processing |
Date: |
Tue, 08 Jan 2013 11:08:25 -0500 |
>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. :-)
Let me double-check to make sure I'm not a liar ... nope, I can't find
an example where the return value of smatch is used in anything other
than a case statement. Ok, there are a few bits of weirdness where
the return value from smatch() is assigned to a variable, but that's
done to check the return value of smatch in a loop (see send.c and
repl.c for examples). It's never used as an index into the struct swit
array.
>> 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.
Oh, sure, use vi tricks :-) Ok, fine, but still even that seems unnecessary
to me.
>True. In that case, do you know the X-macro technique?
>http://en.wikipedia.org/wiki/X_Macro
I think I've seen that before, but I definitely hadn't heard of the
name. I'm not sure that helps in this situation here, though. We
have three distinct bits of information that need to be matched up:
the option name, the minimum abbreviation length, and the value that
needs to be returned. I'm not sure:
X("noaudit", 0, NAUDSW)
is better than:
{ "noaudit", 0, NAUDSW },
>I'd have a temporary vim macro created on the fly mapped to `Q' that
>incremented the current one and moved to the next.
Okay, fair enough. Not incrementing at all would be preferrable, though :-)
--Ken
- [Nmh-workers] nmh internals: argument processing, Ken Hornstein, 2013/01/07
- Re: [Nmh-workers] nmh internals: argument processing, Lyndon Nerenberg, 2013/01/07
- Re: [Nmh-workers] nmh internals: argument processing, Ralph Corderoy, 2013/01/07
- Re: [Nmh-workers] nmh internals: argument processing, Ken Hornstein, 2013/01/07
- Re: [Nmh-workers] nmh internals: argument processing, Ralph Corderoy, 2013/01/08
- Re: [Nmh-workers] nmh internals: argument processing, Paul Fox, 2013/01/08
- Re: [Nmh-workers] nmh internals: argument processing,
Ken Hornstein <=
- Re: [Nmh-workers] nmh internals: argument processing, Ralph Corderoy, 2013/01/08
- Re: [Nmh-workers] nmh internals: argument processing, Ken Hornstein, 2013/01/08
- Re: [Nmh-workers] nmh internals: argument processing, Ralph Corderoy, 2013/01/09
- Re: [Nmh-workers] nmh internals: argument processing, Ken Hornstein, 2013/01/09
- Re: [Nmh-workers] nmh internals: argument processing, Paul Fox, 2013/01/09
- Re: [Nmh-workers] nmh internals: argument processing, Ralph Corderoy, 2013/01/09
- Re: [Nmh-workers] nmh internals: argument processing, Paul Fox, 2013/01/09
- Re: [Nmh-workers] nmh internals: argument processing, Ralph Corderoy, 2013/01/09
- Re: [Nmh-workers] nmh internals: argument processing, Ken Hornstein, 2013/01/09
- Re: [Nmh-workers] nmh internals: argument processing, Ralph Corderoy, 2013/01/09