Hi,
I have noticed that all the line endings (CR/LF) are converted to the selected one (view.line_endings()) on file save.
So, for example if I have a file which has some lines ending with LF and some with CR/LF, even if I don’t change anything on the file, when I save it, all the line endings are unified to Unix or Windows
Is this the expected behavior?
Is there any way to avoid this?
Thanks
I don’t think so, it seems that this setting is to determine the line endings to use in new files
" // Determines what character(s) are used to terminate each line in new files.
// Valid values are ‘system’ (whatever the OS uses), ‘windows’ (CRLF) and
// ‘unix’ (LF only).
"
From what I tested, it doesn’t affect existing files
Thanks
When saving, all line endings will be written with whatever the current line ending is set to: files with mixed line endings will be opened ok, but the line endings are always normalized in memory when the file is opened, so mixed line endings will never be saved.
If I may ask, do you actually have a desire for a file with mixed line endings, or is it a case that you’ve got a file with LF line endings, but with a CR character or two inside that is just supposed to be a CR character, and not a line ending as such?
Thanks for the answer jps
I have a file with mixed line endings. I would like to preserve it as it is. This file is under Version Control Management, so when I change one line, I want only that line changed, so that when I make a diff with a previous version only that line is different. I know I can ignore spaces in a diff and thus ignore line endings, but I need to track space changes also
Isn’t it possible to customize the opening of a file, to prevent the line endings normalization?
[quote=“emilio”]Thanks for the answer jps
I have a file with mixed line endings. I would like to preserve it as it is. This file is under Version Control Management, so when I change one line, I want only that line changed, so that when I make a diff with a previous version only that line is different. I know I can ignore spaces in a diff and thus ignore line endings, but I need to track space changes also
Isn’t it possible to customize the opening of a file, to prevent the line endings normalization?[/quote]
Is preserving line endings a real requirement, or is it a tool artifact? If the only reason for doing it is to get clean diffs, just change the line endings once and for all and forget it.
Is to maintain clean the version management of the files
I have several files in this situation, and various developers in different OS that use different line endings (and they use eclipse, that doesn’t normalize line endings), so even though I can fix the files, they will mess them up again (i know, we should use a standard line ending for every file, but this is another problem).
So each time I modify a file, I will be modifying lines I didn’t even touch, and then when I analyze the history of a file and do a SVN Blame for example it won’t say the real last modification
I think you are looking for a fix in a wrong place.
First of all, stop using SVN. If you are using SVN you are ugly and stupid 
Second, you and your team should decide on a standard. Do you also have some team members that use tabs and some are using spaces?
I guess every other editor have line ending settings. Make the changes and you are done. (or just convert everyone on Sublime and everybody wins)
Okay, so it is a tool artifact, but a more difficult one that simply a version control issue. Still, since you say that you need to look at whitespace in history, it sounds like you need a uniform approach to line endings. There are ways to do that; SVN can run a script on checkin, and that gives you a hook to “fix” line endings.
Thanks for the answers
It’s not so easy to add the hook, I’m not the admin of the repository, so I won’t be able to add the hook, or change SVN to other SCM (in fact we use SVN and Mercurial)
Also I’m not in charge of the team, so I won’t be able to convince the developers to use all the same line endings. I totally agree we should have standards, but it is not always so easy when there are lots of developers from different companies, and there is no unique team
So what I need is when I do a modification in a line, just modify that line, and leave the line endings as they are.
I think normalization of line endings is a great feature but I don’t really need it, and I don’t want it, so if there is no easy way to disable this feature I will look a little more if it is possible to do it through a plugin, but I don’t have too much experience on plugins
Any idea on how to avoid the normalization through a plugin?
There is no way to avoid line ending normalization, nor will there be in the future. Support may be added to preserve CR characters, but this isn’t the same thing as supporting mixed line endings: CR characters would appear as actual characters in the buffer.
Mixed lined endings are something that is going to create issues for many tools. For example, many unix tools won’t handle it, and compiling code with mixed line endings in Visual C++ on Windows will result in incorrect line numbers in error messages.
This would be perfectly fine for me. Is this possible yet? I looked briefly but didn’t see any options or plugins for this.
It’s not acceptable to code reviewers that my patches include changes to whitespace, and I’m not really in a position to make sweeping cosmetic changes to all files that have spurious CRs (and there are many). I can sort of deal with it with “git add -i” but it’s an inconvenience so I’m hoping for way to preserve CRs.
Cheers!
Unfortunately, missing the option, which can stop line ending normalization, is the reason to terminate my using Sublime Text. Why there is so difficult (for anyone) decision to choose system unmixed line ending? Is it really right way to give free hands to user what to do with his file?
There’s a critical type of file which require an editor to don’t touch what is not modified by the user, shell script with embedded binary files, I create a lot of this files to make self contained installation package for some linux projects and any time i open such files with ST to check inside or do some customization it convert also the 0x0D to 0x0A inside the binary part of the file, this corrupt the files making them unusable and all powerful features of ST useless in this case.
As a rule of thumb i think that any editor should absolutely to avoid to apply any modification to a file if not explicitly edited by the user, this is simply because it cannot know what the user is doing. The assumption that any user editing a file would require to have line ends automatically managed by the editor is simply wrong.
I’d like to second the issue pointed out by puccet. I’m doing some work with PDF files, and I’ve been using sublime to check out details in raw PDF files. The fact that sublime converts all 0x0A and 0x0D characters to one or the other, (and especially that it converts adjacent instances of these characters to just one of them) makes it impossible to make any edits to the file from within Sublime. As you may know, a PDF often contains binary streams that get messed up if you remove any characters…
If anyone has any suggestions for how to work with these kinds of files, I’d love to hear from them. Opening files in Sublime using the hexadecimal encoding causes no characters to be changed or substituted, but staring at a long list of hex numbers is real drudgery. Large swaths of a PDF are often human readable with e.g., the Windows 1252 encoding. It’d be great to be able to open a PDF file with the Windows 1252 encoding, make some changes to the human readable parts, and then save the file without having all my 0x0A0A’s in my binary streams collapsed down to 0x0D.
I suggest using a hex editor that also has a preview of ascii characters instead.
I joined this forum just to agree with tomeeec - looks like this is the end of the road for me and sublime, I enjoyed our time together, and maybe we’ll get together again someday. But this won’t work for me on my current team. Nice knowing you, sublime!
I opened a feature request on the Sublime Text core issue tracker for it:
You may vote it up:
Thanks addons_zz - i tried to vote it up and they closed it for being a duplicate.
Today I am using Atom text editor and a colleague just figured out for me how to retain mixed line endings with it - in the packages -> Whitespace uncheck all the options. Then saving files won’t change line endings! Now that this works I have no more need for using sublime. Cheers,
Jon has already indicated the normalization isn’t going to change. Below is an explanation of why:
When loading code, we normalize the line endings in memory. This allows package authors and everyday users to use \n for matching a line break, instead of having to write (\r\n|\n|\r) everywhere. This affects a number of different areas of the editor, including (but not limited to): syntax highlighting, regex find/replace, and settings in .tmPreferences files.
When saving the file, all line endings need to be written to disk, which is done based on the current line endings setting.
Mixed line endings seem to imply editing a binary file, which Sublime Text really isn’t designed for.