Can we support CR line endings as well as LF and CRLF?

[davidgiven]

VSCode supports LF line endings, and CRLF line endings, but it doesn't support CR line endings.

Any chance of support for this? There are some exotic platforms which still require them, such as e.g. pre OSX MacOS, and the amount of work involved ought to be trivial. This is ff=mac mode in vim.

I've tried manually setting files.eol to "\r", but the value is rejected as being invalid.

Right now, if you try to open a CR file in VSCode it gets normalised to CRLF, which is incorrect. At the very least stopping this from happening would be nice.

[jrial]

Duplicate of #31286

[leebehrens]

I have a pile of HL7v2 file I need to edit. VSCode has a couple excellent HL7 extensions that would make VSCode a dream for what I need to do, but the lack of support of CR as end of line is killing that dream.

[medo64]

Are there any changes in the regards to CR line ending support?

May 2020 Release Notes make mention of CR being supported:

VS Code currently recognizes CR (Carriage Return), LF (Line Feed), and CRLF as line terminators.

However, based on my testing, CR is still not supported.

[hopeseekr]

What operating system still uses CR line returns? I am of the understanding that it's extinct in modern platforms.

Why do you want support for it???

[medo64]

For me personally, I found CRs in three places:

1) Electronics: There are plenty protocols that result in CR line endings when dealing with industrial/health devices. HL7 mentioned by leebehjrens is just one of them. Quite a lot of industry controllers are using CR too. I can honestly say I see CR on something still at least once a year (last was internal protocol of CyberPower OR500LCDRM1U UPS). And yes, usually they end up being converted to CRLF (I know :)) or LF immediately on import/capture but I still need to use Notepad++ to check them.

2) Test cases: I often write file parsers (usually to parse various electronics' devices output) and I generally want them to support CRLF, LF, CR, or any mix above. Currently I cannot actually create test files with CR or mixed endings using VSCode. Even worse, VSCode actually actively corrupts those test files by normalizing line endings (see also issue #127).

3) Old computers: It's not just old Mac OS but a lot of golden hardware like C64 and/or ZX spectrum that need CR. I admit that this one is the weakest argument as the vast majority of files I use to play with them is equally old and just copied around. Still, for rare editing sessions, I still have to use Notepad++.

[jrial]

What operating system still uses CR line returns? I am of the understanding that it's extinct in modern platforms.

Why do you want support for it???

Some devs may have legitimate reasons to work with these older formats, e.g. for study, software preservation, or to fix issues with legacy systems that are still in use, and that's just the reasons I could come up with in the time it took me to type it out.

[PJB3005]

My anecdote is that I just went on a 5 minute debugging adventure that could've been a one minute if VSCode didn't misreport this file I had as "CRLF" when it was actually CR.

[xjdfhbv]

The Joomla open-source content management system requires its language files to have CR line endings. It does work with CRLF, but the utility that checks extensions for inclusion in the Joomla Extensions Directory generates a notice (warning) for every language file in an extension that has line endings other than CR. The notice reads "Incorrect end-of-line character found. Convert file to Unix EOL (\n) format".

[jrial]

The notice reads "Incorrect end-of-line character found. Convert file to Unix EOL (\n) format".

That's actually LF, not CR.

CR: Carriage Return (\r) LF: Line Feed (aka Newline, \n)

So fortunately for you, you're not affected by this issue. :)

[xjdfhbv]

Oh how embarrassing. Can we put it down to a senior moment?

[mgautam98]

I am building language server for HL7v2 files which uses \r line endings, waiting for this issue to resolve so It could work with VSCode

[lingyphone]

Please fix this issue.

[DaleMullins]

Is there a technical roadblock on why VS Code can't honor the line endings that are in the file, instead of converting them? I also work with HL7 files and they are far from extinct or legacy. It is an international standard that practically every healthcare organization uses in some capacity. If I open a file with CR line endings, just leave them as they are.

[DaleMullins]

What operating system still uses CR line returns? I am of the understanding that it's extinct in modern platforms.

Why do you want support for it???

Operating system has nothing to do with it. We are talking file formats. Search for "HL7 standard" and you can easily see that it is far from extinct.

[hello-smile6]

What operating system still uses CR line returns? I am of the understanding that it's extinct in modern platforms. Why do you want support for it???

Operating system has nothing to do with it. We are talking file formats. Search for "HL7 standard" and you can easily see that it is far from extinct.

They just need to fix the end-of-line sequence. If the user wants an emoji as their end-of-line character, they may as well have that! It shouldn't matter what the character is.

[lavafactory]

Can't believe this is still an open issue as I have to imagine it would be a dead simple fix. Like most others here, HL7 requires the CR as the EOL character. Just need to add CR as an option to the end of line sequence options

[idolpx]

I vote for this too. I need it some of the projects I work on related to retro computing.

[Jartza]

For me personally, I found CRs in three places:

1. Electronics: There are plenty protocols that result in CR line endings when dealing with industrial/health devices. HL7 mentioned by leebehjrens is just one of them. Quite a lot of industry controllers are using CR too. I can honestly say I see CR on something still at least once a year (last was internal protocol of CyberPower OR500LCDRM1U UPS). And yes, usually they end up being converted to CRLF (I know :)) or LF immediately on import/capture but I still need to use Notepad++ to check them.

2. Test cases: I often write file parsers (usually to parse various electronics' devices output) and I generally want them to support  CRLF, LF, CR, or any mix above. Currently I cannot actually create test files with CR or mixed endings using VSCode. Even worse, VSCode actually actively corrupts those test files by normalizing line endings (see also [issue #127](https://github.com/Microsoft/vscode/issues/127)).

3. Old computers: It's not just old Mac OS but a lot of golden hardware like C64 and/or ZX spectrum that need CR. I admit that this one is the weakest argument as the vast majority of files I use to play with them is equally old and just copied around. Still, for rare editing sessions, I still have to use Notepad++.

In my opinion 3 is nothing like a weak point, there are tens of thousands of retro enthusiasts all over the world 😄

But to add to your list: Lots of industrial machinery still use CR. The machines won't have same life-cycle as consumer electronics. In the last 10 years I've worked as embedded developer in industries where LON, Modbus and such are still valid technologies and files with plain CR line ending as well. It's a pity this simple issue haven't been fixed in 5 years, which forces people to use multiple editors while working in projects ☹️

[charlesg99]

+1

Just got bitten by this and have to admit that for the first time I did swear a bit at VSCode (which I love and do almost everything in).

I opened a giant flat file read/written by a legacy system running on a prehistoric Mac server. Did a small modification and saved. Next was the partial legacy system failure as all EOL were replaced from CR to CRLF. Tried to regex replace all \r\n to \r, but the search widget wouldn't cooperate either as it seems to restrict the allowed EOL character combinations. To fix it, I tearfully had to start the Windows VM and resort to good old trusty Notepad++ which does support CR only.

This would be for another issue but it also converted the macroman encoding to UTF-8 on save as I'm guessing it couldn't correctly detect it when I opened the file. Since the legacy system constantly appends to this file using macroman encoding, well you guessed it, my life turned into a whole lot of little black diamonds. Fun times

[Jeff-Birt]

The thread asking for the ability to use CR line endings is 5.5 years old. Why do we get new themes nobody needs but yet really useful changes this CR line endings are ignored?

[Jeff-Birt]

The thread asking for the ability to use CR line endings is 6 years old. Why do we get new themes nobody needs but yet really useful changes this CR line endings are ignored? Even Notepad can deal with CR line endings for god's sake.

[Jartza]

The thread asking for the ability to use CR line endings is 6 years old. Why do we get new themes nobody needs but yet really useful changes this CR line endings are ignored? Even Notepad can deal with CR line endings for god's sake.

I guess this issue has already been forgotten as "too old to care", probably should be opened as a new issue to raise it in the list.

[simon-20]

+1 to this.

[Atreyu-94]

I was facing this issue too; I fix my script thanks to this StackOverflow response. It seems that some programs are using CR for its outputs (by example cURL). This is very important to making scripts.

[keithy]

Squeak Changes Files (which hark back to MacOS days) Visual Studio code just destroyed a week of work because it converted the line endings without warning. Fortunately Squeak/Pharo knew to warn of this.