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
