Possibility to display line endings in text area

[tonka3000]

• VSCode Version: 1.5
• OS Version: Win 7 x64

At the moment there is only the little statusbar menu which display/change the line ending if the actual file. But sometimes it would be great to see the line endings directly in every line (see atom f.e.) especially when there are mixed line endings (not good, but this happens from time to time).

Greetings
Tonka

[jlarcombe]

Same thing as #24625

[masaeedu]

@alexandrudima Any progress on this front? Keep having to crack open notepad++ or cat -e to see newlines, which is pretty annoying.

[fabulousduck]

Any update on this ?
And it seems that this issue is looping since there are 2 issues that refer to each other (#24625 <> #12223)

[sajidali]

@alexandrudima Any update on this ?

[sajidali]

Add "editor.renderWhitespace": "all" to settings.json
It renders most whitespaces, but not newline characters.

It would be very helpful to render the newline characters, with distinct renderings for CR vs LF. This is especially helpful if you have a mixed line ending file and want to see where the issues are.
@bpasero Is there any chance, someone picks this up and completes this?

[djtrustgod]

@sajidali I agree. I keep having to copy my code into NotePad ++ to see special characters like new lines. I would like to see editor.renderControlCharacters so it behaves.

[ghost]

Any movement on this case for rendering the line endings?

[adamralph]

This issue has been open for almost a year, and seems like very "low hanging fruit" which would benefit a lot of users. Is the team considering implementing it?

[ghost]

@adamralph: perhaps this one is kept unresolved on purpose... there should at least be one or two things that Atom is better at 😉

[Deilan]

@alexandrudima Could you kindly retriage this one? A highly requested feature.

[caigwatkin]

In the mean time, does anyone know of any extensions that implement this feature? Doesn't look like the team are very excited to add this feature anytime soon.

[fabulousduck]

willing to send the person who adds this a snickers bar.
no bamboozles.
I mean, thats a tasty offer

[den-rain]

+1, very needed feature!

[adamralph]

Gentle reminder that lots of people are eagerly awaiting this.

[youngr2]

+1, #26646

If Render Control Characters does not show Newline characters — what control characters are rendered when enabling this setting?

Nearly every other editor I have used with support for rendering control characters does display newlines characters when enabled.

[IbrahimTanyalcin]

This is a frequently used and highly expected feature by the users. Any developer from the VScode side that can give us a timeline of when this feature might be implemented?

[sohamkamani]

I am desperately awaiting this feature as well.
In the meantime, I made an extension to show line endings, in case anyone wants this feature now : code-eol

[adamralph]

@sohamkamani that's pretty cool!

Although I notice that it displays the same character ⬎ regardless of whether the EOL character is LF, CR, or CRLF. The reason I want this feature is to be able to distinguish them. If that's something you'd be willing to implement, I humbly suggest:

• LF = ↓ (DOWNWARDS ARROW)
• CR = ← (LEFTWARDS ARROW)
• CRLF = ↵ (DOWNWARDS ARROW WITH CORNER LEFTWARDS)

These are the characters I've seen used in some other apps. The nice thing about them is that they represent the physical movement of the typewriter head when performing a line feed (LF) or carriage return (CR) and they are additive (downwards arrow + leftwards arrow = downards arrow with corner leftwards).

[sajidali]

Good work, just one more request.
@sohamkamani as @adamralph said, we need distinct rendering for each of line break characters.
I have already asked for the same in the above comments, that distinct displayed character is needed to notice the mixed line ending issues.

It would be great if the official team can provide this basic feature. @egamma, @alexandrudima this is long awaited features waiting for your attention.

[pltrant]

This missing feature is the sole reason I still have Notepad++ installed.

[geekley]

When opening a file with mixed line endings, vscode is still showing it as LF or CRLF in the status bar.
After saving, it fixes it, but I think it should show, for example, LF (mixed) (maybe in red) until the file is modified.
This is important so that you know the file still has mixed EOLs, and you might want to fix that.

To reproduce: printf "lf\ncrlf\r\ncr\rnone" > mixed-eol.txt && code mixed-eol.txt
If you open this file in Notepad++ and enable visible EOL, you can see it has mixed endings.

By the way, this might by why code-eol isn't showing them as different EOLs.
Should I post this in a different issue, as a bug?

[geekley]

This missing feature is the sole reason I still have Notepad++ installed.

I have a second reason: Notepad++ opens instantly.

EDIT: No longer applies nowadays, vscode startup speed has improved a lot since then.

[ericblade]

I am now working in a project where I need to have mixed line endings (some files require LF only), and this is pretty difficult to deal with in VScode. :-S Komodo Edit has the ability to set CR/LF vs LF on specific files. That would be a fantastic addition, for those that need it.

[tanrui8765]

In vscode version 1.36.1, it seems like the problem still exists. Is there a plan to improve this feature?

[andrecasal]

It has been almost 4 years since this feature request. I would never imagine this would be such a hard feature to implement. Are there any updates or a timeline for this?

[DougPlumley]

Any plans to implement this?

[davidc555]

Please, please address this! Thank you

[geekley]

To everyone subscribed to this: You'll likely also want to upvote my feature request here, before it's closed by bot: #119025

The reason most people want to see line endings is because they want to detect and fix mixed endings, right?
For this, I think that it's more helpful to easily know when a file has any mixed line endings (without having to look at it line by line), with option to auto-fix it on save, than to know where a file has a specific line ending (and having to manually fix it).

Knowing "where" is useful mostly in binary files, but you can currently use hex editor if you're dealing with those. It's also useful if you're working on a text file where you want mixed endings on purpose, like testing how compilers and tools deal with such files, etc., but this is an infrequent corner case.

[masaeedu]

The reason most people want to see line endings is because they want to detect and fix mixed endings, right?

Can't speak for most people, but mixed line endings aren't always a problem that need fixing. Or at least that's not why I subscribed to this issue. I was writing a test suite that did some stuff with whitespace and wanted to be able to read the whitespace in my source code.

Knowing "where" is useful mostly in binary files, but you can currently use hex editor if you're dealing with those.

"Use <different editor>" is basically a solution to every feature request on this tracker, but probably not a very satisfying one to the people subscribed.

[geekley]

@masaeedu Sure, I recognize this feature is important too. In fact, the corner case I mentioned is one I'm having to deal with myself, so I'd like to have this as well.
But since the mixed lines case is closely related to this, I thought I'd notify subscribers of a better solution in fixing that particular problem (as complementary to this, not replacement). I wanted to draw attention to that feature request mostly so it doesn't die, not because it would solve the same problems as this, or anything like that.

[lukaszpolowczyk]

I need this feature.
I'm manually copying text from a PDF into MARKDOWN, and I need to delete unwanted new lines.
It can't be done automatically, because some new lines have to stay.

If I could see where the newline mark is, it would make my job a lot easier.
Because I have to distinguish between wrapping a line in the editor and a newline.

Disabling line wrapping is also inconvenient, because I have to move the text sideways...

[DougPlumley]

@lukaszpolowczyk out of curiosity, what's stopping you from deleting the new line characters?

You should be able to go to the end of the line or beginning of the next line and delete them. Just because you can't see the CRLF or LF doesn't mean you can't delete it.

[lukaszpolowczyk]

@DougPlumley I'm deleting, but first I need to guess where the newline character is and where the wrapped line is.

In the PDF file, it goes something like this:

Lorem Ipsum is simply dummy text of the printing and typesetting
industry. Lorem Ipsum has been the industry's standard dummy
text ever since the 1500s, when an unknown printer took a galley of type and scrambled it to make a type specimen book.
It has survived not only five centuries, but also the leap into electronic typesetting, remaining essentially unchanged.

And the editor additionally wraps some lines.

The result is that I have two newline characters to delete, two wrappers that I don't need to delete, and one newline character that should stay.

In the editor I cannot see where the newline is and where the wrap is.

Do you understand now? :D

[trapper2hin]

🧐

[DougPlumley]

@DougPlumley I'm deleting, but first I need to guess where the newline character is and where the wrapped line is.

In the PDF file, it goes something like this:

Lorem Ipsum is simply dummy text of the printing and typesetting
industry. Lorem Ipsum has been the industry's standard dummy
text ever since the 1500s, when an unknown printer took a galley of type and scrambled it to make a type specimen book.
It has survived not only five centuries, but also the leap into electronic typesetting, remaining essentially unchanged.

And the editor additionally wraps some lines.

The result is that I have two newline characters to delete, two wrappers that I don't need to delete, and one newline character that should stay.

In the editor I cannot see where the newline is and where the wrap is.

Do you understand now? :D

Yes and no I suppose, because you can show line numbers and anything that wraps is going to have the same line number.

You can also select a single line feed and Control + D (Command + D on macOS) to select the next word

You can also use search in the file to find, find/replace new lines.

[lukaszpolowczyk]

@DougPlumley Thanks, that's what they'll be doing:

Actually it's obvious, dumb that I didn't figure it out. :P
This will make it a little easier for me. :)

But it makes it all the more strange that Microsoft doesn't want to introduce natively, a similar marking in VSCode.

[Jonadabe]

I don't think that what you're asking is this, but still for who his searching for this gets here, and this could be helpful for many of you like me!
https://stackoverflow.com/questions/29968499/vertical-rulers-in-visual-studio-code

[StephenHodgson]

We're still waiting...

[RubenatorX]

As someone that helps new programmers learn PHP, the fact that there isn't a setting for showing newlines is really unfortunate... for example...

<?php require('thing.php'); ?>
<?php
// code and whatever here
header('Location: /index.php');

this header line does not work because line 1 outputs a newline, but students do not understand that there is a newline character at the end of line 1 that is being output to the response body.

Whereas in Notepad++, the settings can make this mistake perfectly obvious:

[Kemeros]

Would love this feature as well.

There is clearly interest for it.

Hope we get a kind soul interested in this.

Pretty please. <3

[salda]

I want it, but just for diff comparison purpose, because very often I don't see a change and usually it's because of line endings.

[jessdwitch]

We're coming up on 8 years since this was proposed. It'd be wild if this bug went a full decade without attention. And it is a bug. If my config is telling me it's rendering "all" whitespace, but there's exceptions, well then that's not "all" whitespace is it? I can't imagine it'd be super difficult to get the settings to stop lying to users. So alternative solution: change the setting to say "most", drop the "all", and just accept that truly rendering all whitespace is just beyond the technical abilities of VSC.