Re: gEDA-user: gschupdate always eats symbols

[sdb@cloud9.net (Stuart Brorson)]

Hi --

[snip]
> I've noticed this as well.  Several possibilities:
> 
> 	1) Leave things as they are.  This allows for max flexibility with
> 	   the unfortunate increase in rc management complexity.
> 
> 	2) Add another rc file to the mix, commonrc (which would be consistent
> 	   with the system-commonrc file).  Also searched for in ~/.gEDA and
> 	   the local directory.  You can do this yourself today with the
> 	   "load" scheme mechanism.
> 
> 	3) Essentially consolidate everything into one rc file, but still
> 	   support all the current rc files and provide a new rc filename
> 	   which is read in all the files.
> 
> 	4) Eliminate all the *rc files and consolidate everything in one
> 	   rc file.  gedarc or gafrc or such.
> 
> #1, #2, and #3 are the most backwards compatible.  #4 is the least
> backwards compatible.  If anybody has any further ideas/comments, please
> let me know.

I'm in favor of option #4, but phase it in over a couple of releases.
See below. 

[snip]
> >On the subject of RC files, I am also getting 
> >e-mails from folks who are having problems reading/parsing the gattrib
> >RC file because they have placed statements in it which make Guile ill
> >under gattrib, but are fine in other gEDA progs.  The point here is
> >that different progs seem to want different things in the RC files;
> >there is no uniformity to their use.  Or am I wrong again?  :-)  
> 
> 	Yes, you are correct.   There are gnetlist specific commands that
> can only go into gnetlistrc files and likewise gschem specific commands that
> can only go into gschemrc files.

OK, that is interesting.  Gattrib's guile processing is based upon
(i.e. stolen from) gnetlist, but I found that I had to include gschem
RC stuff in the RC file in order to make font stuff work.  Therefore,
gattrib's RC file is an ugly combination of Scheme statements from
gnetlist and gschem.   I had wrongly assumed that the Guile handlers
were tool independent, and so I didn't take a lot of time to study
them.  I admit I don't fully understand how the  gEDA/guile interface
is supposed to work; nasty bugs may be lurking in the gattrib
code. . . . . 

Indeed, one of the complaints/bugs I am hearing about is that gattrib
barfs on certain commands placed in the RC files by the user.  I was
a little baffled by this bug.  Now I realize that it is possible
that I didn't put in the correct handlers from gschem to handle all
Scheme statements which the user put in.  How was he to know which
statements were unique to gschem, and which were valid only for
gnetlist?  How could I know that too?  

This is a strong argument for a single, unified RC file system.

> 	I'm not against consolidation as that would simplify the programs
> a bit (move keyword support/registration routines into libgeda) as all
> rc keywords would be shared by all libgeda programs.  Hmmm.. there might
> be some serious merit to this.

I'd agree with this.  The first thing to do would be to make a list of
all possible Scheme fcns to be supported.  Then, write the libgeda
code to support them -- but only after specing out which fcns to
support.  As always, please let me know how I can help with this!

Stuart