kicad-developers team mailing list archive

[Dick Hollenbeck <dick@...>]

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,

Dick