Sublime Forum

Sublime auto modifies SOME lines on save

#1

Hello,

I noticed weird behavior of my sublime with just ONE of the files - on file save it auto modifies just a few lines of it. What got modified are line endings - ^M got removed. This only happens with sublime - if I modify that file with vim no such problem. I have added two settings:
“default_line_ending”: “system”,
“ensure_newline_at_eof_on_save”: false,
but it did not help. I also can’t find any option like “dont_change_line_endings_on_save”

How to fix that?

0 Likes

#2

ST doesn’t change line endings on save by default.

Check to see if it happens in safe mode. If it does not, maybe some package/plugin is doing unwanted favors for you (In which case, you could disable and re enable the packages one by one and see what is doing it)

I guess it would also help to know what OS & ST Build you are running.

0 Likes

#3

Line endings are always normalized by ST, so if your file has mixed line endings those will be fixed upon saving.

0 Likes

#4

Yes it happens in SafeMode as well. I use Sublime build 4126 which is the latest I guess.

bschaaf, is it possible to disable this normalization?

0 Likes

#5

It is not. It’s inherent to the way ST handles files internally. Why do you want files with mixed line endings?

0 Likes

#6

Well I agree, having a file with mixed line endings is weird…I don’t even know how somebody managed to make it this way, maybe some copy paste? On the other hand though I also don’t like such managerial behavior of sublime. I wanted to commit a small change in that file now I lost an hour trying to figure out why sublime is modifying lines on its own…

0 Likes

#7

Also, what line ending is choosen for this normalization?

0 Likes

#8

Maybe I am biased as git uses autoctrl on Windows and thus cleans up line endings automatically, but
I wouldn’t like any tool/editor, which would cause those to mix up. You can always exclude whitespace changes and line ending changes from git diffs if those changes are not of interest.

New files always use the OS specific line endings. I’d assume all others to use whatever ST finds at the first lines of a file when opening it - very much like it detects indentation.

0 Likes

#9

We use the line ending that most commonly occurs in the first 32KB.

0 Likes

#10

Thanks for the answer. I feel like something is wrong with encoding in that newest ST… in git diff I again SOMETIMES see the file has ALL line endings changed (happened because I modified and saved that file). But again it happens sometimes only! If I do git checkout that_file.c and then just add some random line into that and do git diff again it shows me just that one line modified…that’s why I say happens “SOMETIMES” only. Any idea?

PS: can I rollback to some older version?

0 Likes

#11

Does it happen in safe mode? You can check the line endings under View > Line Endings to confirm whether ST is saving different line endings.

0 Likes

#12

bschaaf: it’s hard to tell as I can’t reproduce it in just single step…I would need to work in safe mode for say the whole day. What I have noticed though is that this project I work on has some files which ST detects as having UNIX line endings and some as WINDOWS. That said how should I setup sublime to it doesn’t change the line endings already present in file?

0 Likes

#13

There isn’t a way to disable line ending detection. Are you sure it’s detecting the line endings wrongly?

0 Likes

#14

I feel like ST detects the file line endings OK but then changes them for unknown reason. This is so annoying. Just now I see entire file got converted from Unix to Windows line endings despite the fact I have "“default_line_ending”: “unix”. :frowning:

Now I can’t see what changes I made as git diff says ALL was changed…please fix that…

0 Likes

#15
	// 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).
	"default_line_ending": "system",

As the comment documents, this setting only controls what the line endings in new files are (i.e. File > New File and related operations); it doesn’t have any bearing on the detected line ending.

Your problem sounds somewhat like core.autocrlf is set incorrectly in your git configuration and it’s checking out files in a different line ending than you expect or similar.

2 Likes

#16

OdatNurd thanks for your suggestion. In fact the problem is more complicated - I noticed that the problem happens only when I use both git bash and msys2 consoles to manage my project. For last two days I was only using gitbash and problem did not occur anymore. This suggest me that msys2 must confuse git so it checkouts these files with wrong line endings.

Sorry I was blaming Sublime but this really puzzled me. Anyway I still think there should be an option in sublime to not change line ending automatically (this is what normalization does).

0 Likes

#17

Git checks out files with normalized line endings (Windows, OSX or Unix). It doesn’t mix things up on its own. So it should be expectable for files to have one style of line endings only. It’s already quite smart by ST to use a heuristic to detect the most used ones in the first chunk of a file instead of using the first one found.

0 Likes