[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: set.q

From: Ben Pfaff
Subject: Re: set.q
Date: Tue, 06 Dec 2005 15:16:38 -0800
User-agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.4 (gnu/linux)

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]