kicad-developers team mailing list archive
Mailing list archive
Re: Re: We should decide a quoting convention...
Dick Hollenbeck <dick@...>
Wed, 23 Dec 2009 08:52:45 -0600
Thunderbird 22.214.171.124 (X11/20090817)
Dick Hollenbeck a écrit :
So I would like to shift the discussion to grammar, and away from this
syntax churn / noise. When I say grammar, I am speaking of a sequence
of tokens & keywords which are returned from the DSNLEXER. Think higher
I committed my notes from mails about new pcbnew file format and layers
This is only some notes about this topic, and *not* a guideline.
This doc is (for me) just more easy to read than a lot of mails.
Dick, please feel free to add/change these notes.
I also believe thinking about a higher level to code footprints,
tracks, rules and the full board and/or footprint libraries files is the
(I did not work on it until now, because I had some work to fix bugs
found in kicad)
By the way, I will be away these 4 next days.
Me too after today, and a tad longer than that.
I revised the document, with special emphasis on the "Identifiers and
I have reversed my opinion on supporting mutli-line strings in
DSNLEXER. I don't like what this does to the line number tracking. One
of the main drivers for using DSNLEXER is its outstanding support of
identifying the location of problems in the input, which is far superior
to any XML parser that I have seen. (Not to mention the better
readability of the lispy format over XML.)
So I will be backing out the support of multi-line strings, but keeping
the other changes I mentioned yesterday, including handling comments and
Grammars can simply use "this is first line\nThis is second line" type
encoding to offer up multi-line string support to their clients. We
have some experience with that already.