Sublime Forum

All Line Endings are converted on file save

#4

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?

0 Likes
#5

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?

0 Likes
#6

[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.

0 Likes
#7

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

0 Likes
#8

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 :smiley:
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)

0 Likes
#9

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.

0 Likes
#10

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?

0 Likes
#11

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.

0 Likes
#12

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!

0 Likes
#13

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?

1 Like
#14

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.

0 Likes
#15

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.

0 Likes
#16

I suggest using a hex editor that also has a preview of ascii characters instead.

1 Like
#17

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!

0 Likes
#18

I opened a feature request on the Sublime Text core issue tracker for it:

  1. #182 Handling of files with different line terminator character sequences (NL and CR)
  2. #1505 All Line Endings are converted on file save

You may vote it up:

1 Like
#19

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,

1 Like
#20

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.

4 Likes
#21

Then once detected a file is within multiple line endings, instead of forcing it to, ask the user to choose between converting the line endings or disable all the features not prepared to deal with this file.

This enters on the same category as on the performance for increased big files. Within the required architecture changes for Sublime Text to support them, you may easily use it for opening mixed line ending files.

Related threads:

  1. #9832 Sublime Text performance with very large files
0 Likes
#22

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.

1 Like
#23

Two things:

  1. I want to register my frustration as well that ST can not be prevented from making more changes to a file than what I specifically specified. There are situations where multiple constraints corner someone into a situation where this is unworkable.

  2. I can appreciate the technical problems @wbond detailed and I’d like to sincerely thank him for providing a reasonable answer for why this feature will never be supported. There are all kinds of trade-offs in software development, and I can understand that it may legitimately be the case that the effort to support these use cases outweighs the customers lost as a result of not supporting them.

    The official responses prior to @wbond’s basically amounted to “you’re wrong for needing this feature”, which is less-than-helpful and even arguably not true. On the other hand, “We’re not ever going to support this use case; you will need to find another tool: Closed - Won’t Fix” is, in my view as a developer, a valid answer.

</$0.02>

0 Likes