Re: set.q

[John Darrington]

On Tue, Dec 06, 2005 at 03:16:38PM -0800, Ben Pfaff wrote:
     >
     > 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.


I agree that would be a better way of doing it, and I did think about
that approach. My proposal however is a compromise which reuses  the
existing code, and can (I think) be done in a lot less man-hours.

Are you happy for me have a go along the lines I suggested?  We can
reserve the option to implement the set_*() method at a later date.

J'

-- 
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://pgp.mit.edu or any PGP keyserver for public key.

pgpcFcFM08RqW.pgp
Description: PGP signature