Sometimes the best "bug" are the troll posts, although personally I agree with it (even though a separate byte for both \r and \n make sense to keep for other purposes).

The proper response to this is that this is the correct behavior, since moving the line down (newline) and moving the output point to the beginning of the line (linefeed) are indeed conceptually separate and have different uses. The Unix conflation of the two is arguably harmful, since it perpetuates the confusion between the two by making newline do both. While I agree that newline-only is much easier to think about and type manually, I also acknowledge that occasionally Microsoft made the technically correct design decision and this is one of them.

(Yes, I am aware this is probably a troll, but other people might not be, so it's still worth explaining.)

@powerfulparadox Very well put. Good job!

@powerfulparadox I think it did make sense in the typewriter era, however, nowadays it makes no sense to separate both.

On a computer, you rarely do \n without a \r, and if you need to do it, you can use ASCII escape sequences to position the cursor right where you want.

On top of that, on linux you can use \r in the same way you can on windows, it is only \n that changes.

@powerfulparadox agreed that for a cursor \r\n is the appropriate syntax in my opinion (that's why there should be two characters).

However in a document there is *no* guarantee things could be displayable exactly below each other, hence no need for double bytes per line.

@powerfulparadox I disagree. I cannot think of any informational use of splitting these supposedly separate concepts up in a way that is universal to all consumers of that data.

If it happens to make sense in the interface you are using that a newline should *not* return the cursor to the beginning of the line, the implementation of that interface should handle the re-indenting. But in my mind this notion has no place in a file, because it’s no longer representing raw data but is now dependent upon implementation-specific behaviour.

@devios1 thanks for speaking my mind 😊

@devios1 It's a remnant of the days of teletype and terminal outputs. Yes, the modern world doesn't need that anymore, but when DOS (and UNIX) was designed it was arguably useful to store things that way and not be dependent on a device driver to guarantee the correct behavior.

I wasn't intending to argue that it should still be that way, but the DOS source code is different. It's a historical artifact and should be treated as such.

I'm watching the follow-up reply tho 👀