[snip] >> I'm tired. Are you saying you prefer without the "[]", but that we >> should emit each segment on multiple lines by default? > >I support this, using the num_lines field as a num_segments check. > >I'm not wildly keen on re-using [], TBH. I feel that a [] should always=20 >imply "sub-schematic", i.e. containing normal gEDA objects. >
So we are talking about: H 3 0 0 0 -1 -1 1 -1 -1 -1 -1 -1 4 M 410 240 L 501 200 L 455 295 L 435 265 Hmmmm. The only problem with this is the M's and L's. Those are specific to the path and have nothing to do with gschem's L's. Imagine what would happen if the num_lines parm was off by one. :) I'm still not leaning towards any one approach. We have three now: - the original that Peter had with the commas and one line; - the next one that reuses [ ]'s; - the above one with num_lines equal to num_segments Here's another possibility: H 3 0 0 0 -1 -1 1 -1 -1 -1 -1 -1 X ( M 410 240 L 501 200 L 455 295 L 435 265 ) Not sure if you would need the above X? I'm okay with introducing ( ) for this since it is new (I think). We could also say that ()'s can be used for future purposes in different contexts (suppose we introduce another object type that needs to take a list of points) so that people write their parsers with this in mind now. Thoughts/comments? -Ales _______________________________________________ geda-dev mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
