Feature request: recognize the line break in multi line string
I thought in most projects, the \n did the right thing DEPENDING UPON the
platform it was running on.
So if you are on windows, \n becomes technically a \r\n, on mac and linux,
just \n.
\r shouldn't even be in there, IMO.
--
Extra Ham Operator: K7AZJ
Registered Linux User: 275424
Raspberry Pi and Arduino developer
The most exciting phrase to hear in science - the one that heralds new
discoveries - is not "Eureka!" but "That's funny...".- Isaac. Asimov
I
*f you give someone a program, you will frustrate them for a day; if you
teach them how to program, you will frustrate them for a lifetime. *-
Anonymous
If writing good code requires very little comments, then writing really
excellent code requires no comments at all!- Ken Thompson
On Mon, Sep 14, 2015 at 3:13 AM, Alan Cox alan@lxorguk.ukuu.org.uk wrote:
On Sun, 13 Sep 2015 20:22:19 -0500
"G. Wade Johnson" gwadej@anomaly.org wrote:
On Sun, 13 Sep 2015 19:49:53 -0400
doug moen doug@moens.org wrote:
Alan Cox said "There are systems that just use \r."
Not any more, and not for a long time. Apple dropped support for Mac
OS 9 in 2002, and OpenSCAD seems to have started in 2009. Xt has also
never supported MacOS 9. You've never been able to create a text file
with \r line separators on any system that supports OpenSCAD, and
those systems likely only exist in computer museums nowadays.
Less than a month ago, I got an example data file from a company that
was using \r as a line separator. I don't know for sure where they got
it. (Of course a quick one-liner converted it to something reasonable
for me.)
Until that time, I believed that you were correct. Now, I'm not sure I
would discount Alan's comment so quickly.
Ignoring the \r isn't the way to do it. The logic is trivial to do it
right
\r\n -> one newline
else
\r -> one newline
else
\n -> one newline
else
literal character
Alan
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Alan Cox wrote
\r\n -> one newline
else
\r-> one newline
else
\n -> one newline
else
literal character
Maybe move \n to the 2nd condition ?
$ Runsun Pan, PhD
$ -- libs: doctest , faces ( git ), offliner ( git );
tips: hash( 1 , 2 ), sweep , var
$ -- Linux Mint 17.1 Rebecca x64 + OpenSCAD 2015.03.15/2015.04.01.nightly
--
View this message in context: http://forum.openscad.org/Feature-request-recognize-the-line-break-in-multi-line-string-tp13789p13823.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
On Mon, 14 Sep 2015 07:10:21 -0700 (MST)
runsun runsun@gmail.com wrote:
Alan Cox wrote
\r\n -> one newline
else
\r-> one newline
else
\n -> one newline
else
literal character
Maybe move \n to the 2nd condition ?
Got a bikeshed to paint ?
Alan Cox wrote
On Mon, 14 Sep 2015 07:10:21 -0700 (MST)
runsun <
runsun@
> wrote:
Alan Cox wrote
\r\n -> one newline
else
\r-> one newline
else
\n -> one newline
else
literal character
Maybe move \n to the 2nd condition ?
Got a bikeshed to paint ?
The idea is to move more frequently used condition to the top so to reduce
unnecessary checking.
But, maybe more checkings is better.
$ Runsun Pan, PhD
$ -- libs: doctest , faces ( git ), offliner ( git );
tips: hash( 1 , 2 ), sweep , var
$ -- Linux Mint 17.1 Rebecca x64 + OpenSCAD 2015.03.15/2015.04.01.nightly
--
View this message in context: http://forum.openscad.org/Feature-request-recognize-the-line-break-in-multi-line-string-tp13789p13826.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
Copying G.Wades's post from the other thread. My comment next.
G. Wade Johnson wrote
On Mon, 14 Sep 2015 06:21:33 -0700
Jerry Davis <
jdawgaz@
> wrote:
I thought in most projects, the \n did the right thing DEPENDING UPON
the platform it was running on.
So if you are on windows, \n becomes technically a \r\n, on mac and
linux, just \n.
\r shouldn't even be in there, IMO.
Whichever tool you are working with normally handles line endings
correctly for the platform they are on (modulo little issues like
Windows text/binary modes).
The problem comes when you get files from a different system...
Some tools can handle the variations, and we are talking about adding
that feature to OpenSCAD. It isn't really as much of a problem in the
whitespace, but when a newline occur in a string, more thought is
needed.
Just my 0.02.
G. Wade
Newly minted Admin - PM me if you need anything, or if I've done something stupid...
Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above.
The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/ time is running out!
View this message in context: http://forum.openscad.org/Feature-request-recognize-the-line-break-in-multi-line-string-tp13789p13832.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
Alan Cox wrote
Got a bikeshed to paint ?
You should really include a reference http://bikeshed.com/ when you
post such.
Newly minted Admin - PM me if you need anything, or if I've done something stupid...
Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above.
The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/ time is running out!
View this message in context: http://forum.openscad.org/Feature-request-recognize-the-line-break-in-multi-line-string-tp13789p13833.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
What we are talking about syntactically is Line continuation
https://en.wikipedia.org/wiki/Comparison_of_programming_languages_%28syntax%29#Line_continuation
.
The OP wishes the CR character to be a continuation (not a token) when
within the scope of a text string, ie between two string tokens ("), as
default behaviour.
While I have not seen examples of multi-line strings in the wild, I can see
how it would be used with the current behaviour.
string="
a bunch of lines,
a bunch of lines,
a bunch of lines,
\n
a bunch of lines,
a bunch of lines,
a bunch of lines,
\n
a bunch of lines,
a bunch of lines,
a bunch of lines,
\r
";
As such I think the chances of breaking existing code is high.
I think that the OP issue is, probably, more of a problem with command-line
use. Perhaps a run-time flag?
--stringseperator:[none|preserve|platform|LF|CRLF]
But in summary, I think it is much easier for the operating system/scripts
etc to fix it, than to try to interpret what the intent is.
Finally, given what the following does, I don't think it should be changed.
s1="def\nghi";
s2="jkl\r\nmno";
s3="jkl
\n // comment - actually string text
nmno";
s=s3;
for(i=[0:len(s)-1]) {
echo(s[i]);
}
Newly minted Admin - PM me if you need anything, or if I've done something stupid...
Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above.
The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/ time is running out!
View this message in context: http://forum.openscad.org/Feature-request-recognize-the-line-break-in-multi-line-string-tp13789p13834.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
G. Wade Johnson wrote
The problem comes when you get files from a different system...
Some tools can handle the variations, and we are talking about adding
that feature to OpenSCAD. It isn't really as much of a problem in the
whitespace, but when a newline occur in a string, more thought is
needed.
Python has much larger user space and a lot more fields of application. If
python can handle files from different systems, then this cross-platform
issue shouldn't become a problem for openscad.
$ Runsun Pan, PhD
$ -- libs: doctest , faces ( git ), offliner ( git );
tips: hash( 1 , 2 ), sweep , var
$ -- Linux Mint 17.1 Rebecca x64 + OpenSCAD 2015.03.15/2015.04.01.nightly
--
View this message in context: http://forum.openscad.org/Feature-request-recognize-the-line-break-in-multi-line-string-tp13789p13838.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
MichaelAtOz wrote
The OP wishes the CR character to be a continuation (not a token) when
within the scope of a text string, ie between two string tokens ("), as
default behaviour.
Really? I thought he was asking for the opposite.
There does seem to be a lot of talking at cross purposes here. What we are
talking about here is specifically how are control characters handled in
quoted strings.
OpenSCAD uses a lexer built with flex. The code for strings looks like this:
" { BEGIN(cond_string); stringcontents.clear(); }
<cond_string>{
\n { stringcontents += '\n'; }
\t { stringcontents += '\t'; }
\r { stringcontents += '\r'; }
\\ { stringcontents += '\'; }
\" { stringcontents += '"'; }
{UNICODE} { parser_error_pos -= strlen(lexertext) - 1;
stringcontents += lexertext; }
\x[0-7]{H} { unsigned long i = strtoul(lexertext + 2, NULL,
16); stringcontents += (i == 0 ? ' ' : (unsigned char)(i & 0xff)); }
\u{H}{4}|\U{H}{6} { char buf[8]; to_utf8(lexertext + 2, buf);
stringcontents += buf; }
[^\\n"] { stringcontents += lexertext; }
" { BEGIN(INITIAL);
parserlval.text = strdup(stringcontents.c_str());
return TOK_STRING; }
}
The sequences "\n" and "\r" are de-escaped and added to the string. I can't
figure out where raw CR and LF are handled, but they appear to be ignored?
--
View this message in context: http://forum.openscad.org/Feature-request-recognize-the-line-break-in-multi-line-string-tp13789p13840.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
Von: bobc bobcousins42@googlemail.com
The sequences "\n" and "\r" are de-escaped and added to the string. I can't
figure out where raw CR and LF are handled, but they appear to be ignored?
I did not fully test all the combinations yet, but I think the unquoted \n
is explicitely not handled in
[^\\n"] { stringcontents += lexertext; }
hence it's ignored. As I did not get any stray \r in GUI mode when using
DOS file format, so I guess the QTextStream already translates everything
to just \n. Command line might be different as it's not using Qt.
As said before, the main question is not how to implement it, but IF it
should be changed (or just put on the big heap that is wishes for the
OpenSCAD2 language ;-).
ciao,
Torsten.