kicad-developers team mailing list archive
-
kicad-developers team
-
Mailing list archive
-
Message #10991
Re: About the sexp format
On Wed, Aug 14, 2013 at 01:44:32PM -0500, Dick Hollenbeck wrote:
> I like our format and it works. I am unwilling to change it for a single user of lisp.
It was just a proposal to make it more amenable to other languages to parse...
parsing 470p as a string without expecting a string is tricky. And,
anyway, is completely backward compatible (and even better
you recognize strings from keywords).
Anyway if you are unwilling to take even a backward compatible
enhancement, I have no problem, I'll keep the modification for myself.
> a) see OUTPUT_FORMATTER::Quote{s,w}
Thanks, I found it. To try I simply removed the initial if in Quotes and
everything works as expected. Except a little buglet, which is harmless
without forced quoting, but it nonetheless 'formally' incorrect:
in PCB_IO::format( TEXTE_MODULE* aText, int aNestLevel ) the text type
(which is a keyword, not a string) is passed to the quote string (so
forced quoting breaks the keyword). I handled it like the hatch type
a little below:
@@ -1207,13 +1207,13 @@
{
MODULE* parent = (MODULE*) aText->GetParent();
double orient = aText->GetOrientation();
- wxString type;
+ std::string type;
switch( aText->GetType() )
{
- case TEXTE_MODULE::TEXT_is_REFERENCE: type = wxT( "reference" ); break;
- case TEXTE_MODULE::TEXT_is_VALUE: type = wxT( "value" ); break;
- default: type = wxT( "user" );
+ case TEXTE_MODULE::TEXT_is_REFERENCE: type = "reference"; break;
+ case TEXTE_MODULE::TEXT_is_VALUE: type = "value"; break;
+ default: type = "user";
}
// Due to the Pcbnew history, m_Orient is saved in screen value
@@ -1222,7 +1222,7 @@
orient += parent->GetOrientation();
m_out->Print( aNestLevel, "(fp_text %s %s (at %s",
- m_out->Quotew( type ).c_str(),
+ type.c_str(),
m_out->Quotew( aText->GetText() ).c_str(),
FMT_IU( aText->GetPos0() ).c_str() );
I am happy to see that layer names *are* quoted, so future expansion is not impeded.
> b) see <kisrc>/Documentation/s-expressions.txt
I'll look in it.
> c) keywords are always lowercase ASCII. The rest of the file is UTF8 with no restrictions
> on case.
Ok, so case is significant
> d) multiline strings in the datatree are single line strings in the file, with a separator
> of "slash n", visible.
Thanks for the info, it hasn't changed too much then
--
Lorenzo Marcantonio
Logos Srl
Follow ups
References