Re: set.q

[Ben Pfaff]

John Darrington <address@hidden> writes:

> On Tue, Dec 06, 2005 at 08:17:11AM -0800, Ben Pfaff wrote:
>      John Darrington <address@hidden> writes:
>      
>      > I want to do some fairly deep modifications to set.q --- essentially
>      > to separate the definitions of the settings from the state variables
>      > which control the SET command.  
>      >
>      > This will affect q2c and *.q
>      >
>      > Anyone got any problems with this?
>      
>      Can you explain further?
>

[...]

> It'll generate two structs:
>
> struct cmd_foo {
>  int sbc_bar;
>  int sbc_wiz;
> };
>
> struct defn_foo {
>  long bar;
>  long wiz;
> };
>
> Optionally, q2c can dump the 2nd one in a separate header file.
> The details I expect to discover as I try things out.  
>
> You see the gui needs to be able to inspect the current state of
> things like cc_{a,e}, but I don't want it to have to depend upon the
> code for parsing the SET command (or any of the lexer stuff).

I think the real problem here is that we have two purposes, which
are parsing and storage of settings, and we are using a single
entity, the structure generated by q2c, for both.  That's ugly.
Instead of making q2c better fit storage of settings, which is
not what it is designed to do, I'd much rather separate the two
purposes into two sets of code.  That is, add a settings.c and
set_*() functions that correspond with the existing get_*()
functions.  Then set.q just becomes a client of settings.[ch]: it
parses the option settings and passes them to set_*().  The GUI
can be another client.
-- 
Ben Pfaff 
email: address@hidden
web: http://benpfaff.org