← Back to team overview

kicad-developers team mailing list archive

Re: Re: We should decide a quoting convention...


jean-pierre.charras@... wrote:
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
level now.

I committed my notes from mails about new pcbnew file format and layers handling.
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 main topic. (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 Strings" section.

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 embedded quotes.

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.

Merry Christmas,


Follow ups