The responses in this thread are absurd and I believe to be inconsistent with standard expectations from ST. When you open a file in a "hacker" text editor like ST, you expect the editor to behave appropriately. I don't believe that it's impossible for you to just retain the line endings the way they are until they are changed. If you have to literally change the data to meet your coding practices, your coding practices are incorrect. You need to fix the libraries you use to handle line endings so that you can leave the data alone.
Here's a scenario where this problem breaks: analyzing a file for inconsistent line endings. I use ST to do a lot of things, one of those things is analyzing the data structure of files. I work with really large files so often running the entire file through the hex converter isn't optimal or even possible. Additionally, running the entire file through the hex converter requires to you actually look through then entire hex structure of the file. So, to get around the filesize and reduce the scope of my search I: open the file in ST, get rid of all except for the snippet of text I'm trying to look at, and then save the file as a snippet (text file but smaller). I then convert the snippet to hex using the hex plugin. This has seemingly worked fine for as long as I've been using ST to do this. However, recently I was analyzing a file that had inconsistent line endings. The inconsistent line endings was causing SQL Server BULK INSERT to skip rows where the line ending isn't correct. ST obfuscated the problem by making the file look as though it had consistent line endings. I ended up chasing my tail around for months because this problem wasn't clear.
Correcting the problem with SQL Server IS as simple as exporting the file with consistent line endings. Unfortunately, that requires that the problem be identified in the first place. And that is where ST failed me.