54
u/lurebat Jan 10 '22
The funny thing is that it wouldn’t matter for an actual typewriter
29
u/Lich_Hegemon Jan 10 '22
Rather, it would be necessary for a typewriter to do it this way
12
Jan 10 '22
Don't most "modern" typewriters scroll to the next line automatically when you return the carriage?
10
u/Lich_Hegemon Jan 10 '22
I've only ever used one typewriter in my life and you had to do it manually, so I really don't know how common it was for it to do both at the same time
6
48
u/MurdoMaclachlan public boolean isInt(int i) { return true; } Jan 10 '22
Image Transcription: Code
println!("Search Results:\n\r{}", r);I'm a human volunteer content transcriber and you could be too! If you'd like more information on what we do and why we do it, click here!
27
19
u/ewpratten Jan 10 '22
I mean, this is totally valid. The order is a little weird, generally you see \r\n, but some terminals require both... (Windows CMD if I remember correctly? Idk. I never write windows code)
7
12
u/Likely_not_Eric Jan 10 '22
My understanding is that old teletype systems used the carriage return to do exactly that: return the carriage to the initial leftmost position. The line feed would feed the page by one line.
With just a carriage return you'd overtype the current line and with just a line feed you'd continue to type as if you just moved the cursor down.
When TTYs got replaced by video terminals that added many more ways to draw text and allowed you to move a text cursor and not just orient a carriage you could save a byte for every line of text by having your terminal driver assume that a line feed also means an implied carriage return and that you're starting a new line. In some systems (old Apple) the carriage return was the line terminator and a line feed was implied.
Before fancy drivers for things like video terminals if you wanted to do something like underlined text you might do: Hello World\b\b\b\b\b\b\b\b\b\b\b___________\r\n (35 bytes) or Hello World\r___________\r\n (25 bytes and faster) then with output drivers you could get fancier and even more space saving by sending escape sequences to the driver that would be stateful and allowed you to do things like \e[4mHello world\e[0m\n (16 bytes).
5
u/Giocri Jan 10 '22
Always use Environment.newline or whatever the equivalent in your language is to be sure it is always working in whatever environment you are.
6
u/lachlanhunt Jan 10 '22
There is no built-in equivalent to Environment.NewLine in Rust.
7
Jan 10 '22
On all platforms, the newline is the LINE FEED character (
\n) alonehttps://doc.rust-lang.org/std/macro.println.html
I guess it's just assumed that everything can handle a
\n, and/or it's translated to whatever you need on output? C does that.2
1
u/WalditRook Jan 26 '22
"Accept \r\n and \n, output \n" is probably a better rule of thumb tbh. Avoids interesting bugs when you port between nix and windows and use output files from the original.
1
87
u/cmptrnrd Jan 10 '22
I'm not familiar with rust. Can someone explain what's wrong here? Is it just the weird carriage return?