Any experts on characters know anything about there being a vital need to always use CrLf and not just Cr?

Consider this code…


This produces this output…

'\r' Cr really isn't working like a linefeed.

Just using \r is causing all manner of strange output.
and loading text containing an '\r' into say a TextEditor object was giving me text overlapping errors in places.

Am i missing some need to know info about escape characters and the need to use CrLf and not just Cr with the Print command here or could i have found a bug?
(I've reported a few bugs of late, starting to feel like I'm pestering Benoit especially when he has to tell me it's not a gambas but its a gtk bug or somethijng like that, so trying to find if i'm just being an idiot here lol)

Cheers all

Its a bit of a Unix oddity in some ways.
CR = "\r" = carriage return, and should return the carriage on a typewriter back to the beginning of the current line.
LF = line feed, and strictly speaking should move on to the next line, but not return to the beginning of a new line.
CrLf makes sense because it returns the carriage to the beginning of the line, then moves on to a new line.

In Unix/Linux LF ("\n") moves the cursor to the beginning of a new line (on Windows you must use CrLf to do this, on classic Mac you use "CR").
In Unix/Linux CR ("\r") simply moves the cursor back to the beginning of the current line.

BruceSteers said

… use CrLf and not just Cr?

"\r" character can be useful when printing strings repeatedly on the same line.
Here is an example by activating gb.media Component:

Aah , Carriage return ,, like a typewriter , thank you folks, makes perfect sense now.

and yes i see how that could be useful indeed

I ran into a trap finding that \r only worked as a linefeed not \n on a tooltip for gtk. and wasn't settable in the GUI as it only saved with LF.
And was loading the strings into a TextEditor control and getting issues.
Then I found \r didn't work on qt but \n did.
Have since found that using \r\n resolved the issue on older gambas editions and Benoit has fixed it in the new commits that the IDE toolTip box translates Lf to CrLf now so works on both.

Thanks again folks, very enlightening

The CR - LF thing is something that can trip-up anyone from time to time.

I'm very used to the ASCII character set and viewing text files in a Hex editor (currently use the Bless Hex Editor) and I recommend anyone interested in software to play around with text files in this kind of editor, where LF = 0A hex and CR = 0D hex.

If you are writing code to drive some peripheral devices (maybe 'tally-roll' type printers or simple multi-line LCDs) you may find that LF moves the print head to a new line but does not return to the left, and CR returns the head but does not advance to a new line). You just have to follow their specs and feed them what they require.

If you wanted to create a cross-platform text editor (where Linux files can be edited on Windows, and Windows files edited on Linux) you can image that it can get complicated. Editors like Geany have selectable default 'end-of-line' characters for Linux, Windows & Classic Mac.

And for anyone really interested (…and very keen) maybe read this: Newline - Wikipedia

 I learned to program with punch cards.  The "cr" solo was important on line printers to be able to do stuff like underlines.

The I move up to a teletype remotely hooked up to a IBM 360.  There the "lf" + "cr" was literally needed.  The "cr" made the carraige return (a massive thing caught by an air scoop), made the whole teletype shake.  The "lf" was literally needed to advance the paper roll.  All very mechanical.  The punch tape was our "mass storage".

And we had to walk to school, five miles, up hill both ways.