Hi Bertho, Agreed on all points. To be clear, I was not suggesting mandatory quoting either, only when a value needs to contain # or ; literally. Unquoted values should remain the default.
The parse procedure you outlined looks right to me. And yes, no spaces in variable or section names, full agreement from me. Luca On March 29, 2026 6:40:19 PM GMT+08:00, Bertho Stultiens <[email protected]> wrote: >On 3/29/26 12:11 PM, Nicklas SB Karlsson wrote: >>> Treat # or ; as an inline comment delimiter by default, and only >>> require quoting when a value legitimately contains those >>> characters: >>> SPEED = 1000 # max rapid speed >>> MY_VAR = "value with # in it" >> Agree. Could see a need for a escape character for " character >> otherwise not possible to add this character to string. >I can see the appeal. You definitely need an escape for '"' and we may then >want to support: >VAR_DQ = "double quote \" value leaving ' alone" >VAR_SQ = 'single quote \' value leaving " alone' > >And then you want to support \r\n\t\v\f\e\b\a and probably also \xHH, \0[nn] >and \uXXXX (translated into UTF-8) when enclosed in double quotes (and not >allowing embedded NUL chars). > >If strings are quoted, then it is slightly inconsistent to use allow unquoted >strings. However, it is a necessity to do so or we could no longer use plain >versions of number sequences like: >VAR_NNN = 0 1 2 3 4 5 >Used as position/pose, parsed in the program(s) from string. > > >>> Continuation lines can coexist with this just fine: if a line ends >>> with \, continue to next line. Otherwise, # or ; starts a comment. >>> No conflict there. But is this even something that is supported? I >>> have not seen it in configurations or in the docs. >> \ is what is used in C macros defined with #define so agree with >> this syntax. Same for string quotation with " and this is good. >The parse procedure would then be: >1 - read line >2 - if continuation merge, goto 1 >3 - split at '=' >4 - left/right trim >5 - detect strings > > >BTW, I still don't think we should allow embedded spaces in variable and >section names (even though python's configparser allows it). It is IMO very >bad style and confusing to use spaces in identifiers. > >-- >Greetings Bertho > >(disclaimers are disclaimed) > > > >_______________________________________________ >Emc-developers mailing list >[email protected] >https://lists.sourceforge.net/lists/listinfo/emc-developers _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
