← Back to team overview

kicad-developers team mailing list archive

Re: Eeschema Default Library Field Names


Wayne Stambaugh wrote:
I haven't looked at JP's changes yet. I was the one who originally proposed getting rid of the .mdc file. I got a little side tracked with all of the things I was working on. I'm almost done with my new EEschema find dialog work. Once the next release is out, I'll commit the new find work then I'll revisit getting rid of the .mdc file. If I remember correctly, I wasn't really happy with changes to the component library file format using my original concept. Then Dick started working on his DSN lexer so I thought I would wait until he got that stabilized and then use it for the new library file format. I'll see if I can make getting rid of the .mdc file and moving to a DSN style file format at the same time. I'll make sure not to break reading the current file format. This shouldn't effect anything you are planning on doing.



The latest TODO.txt file talks about the need for a simple tool which will generate the keyword tables for any grammar. With this tool, you should only have to maintain a single text file of keywords for each grammar.

I would say the description of the needed tool is pretty good in the TODO.txt file, and most anyone could write it.

Whoever gets to it first would be what I suggest. Eventually I will if no one else does.

You can see a simple example of a recursive descent parsing environment at the bottom of the dsnlexer.cpp file. It could also be the basis of clipboard pasting support. For copying support, there is the STRING_FORMATTER to generate a string in ram.

The first keyword after the opening '(' can be used to vector to a keyword specific paste function, and invoke a different parser, depending on what is on the clipboard. There are many examples of parsing recursively in the specctra import code.

The LINE_READER foundation gives very exact location specific error messages when the input is bad. I realized I had broken this concept when I started returning multi-line strings as single tokens. There was no way to say exactly on which line an error occurred when I started returning multi-line strings. So I backed off and now all tokens must reside on a single line, and purely for the purpose of an exact error message. It will output the exact line number and character offset.

Just loading a library file with a text editor and converting to a DSN format should be pretty easy. It might be reasonable to START with clipboard support, this way you do not have to commit to a file format change until folks like it.

VESA and the library crew can copy a symbol from the symbol editor to the clipboard, paste from there to a text editor, edit in a text editor, and paste back into the symbol editor via clipboard. If you could just offer this much support, based on the notion that exact error messages will be issued, and that the new format is SELF DOCUMENTING, it should be good value, and a win IMO.

No need to wait for me any more (at least not on this subject) :-)

Doing the tool will clarify in the writer's mind what is required to generate the enum {} and the keyword table.


Follow ups