Sublime Forum

BUG: Shows <0x0d> on all files with CRLF since update

#1

image

For reference, my global git config has core.autocrlf set to false. Adding eol to gitattributes doesn’t fix it. Was fine before I updated.

It’s especially annoying because the way its copied causes every CRLF to seemingly become CRLFLF or CRLFCRLF, so you have an empty line after every copied line.

1 Like
#2

That’s desired behavior according to changelog

grafik

0 Likes
#3

There’s no way the copy behaviour of this is desired.

And I looked at the settings up and down, there is no “newline normalization.”

0 Likes
#4

Hi @Sainan,

Thanks for reaching out.

This was an intended change based on feedback that users were missing CRLFs accidentally being introduced into their repositories, as we were hiding them in cases where Git shows them. By default, Git will render carriage returns in diffs unless autocrlf is enabled, or the text/eol attribute has been set on a file.

There is currently a bug with the gitattributes processing, where Sublime Merge is not enabling end-of-line normalization when the eol attribute is set and the text attribute is not. We’re addressing this currently, and this will be resolved in the next build.

For the moment, you can either disable the carriage return rendering with:

  • the git config option git config core.whitespace cr-at-eol (which will disable carriage return rendering in all diffs)
  • Enabling the text attribute on the applicable file
  • Enabling autocrlf

Kind regards,
- Dylan from Sublime HQ

1 Like
#5

Hi @djohnston,

I would like to second this bug/request.
After the latest change my diifs have become very distracting to look at.
For complicated reasons my compiler yells at me for every file with “non-native line-endlings”, so I can’t really remove the CR’s

Making this a feature to turn on/off (even if on by default) would be a great help.

// Thank you for the awesome product!
// Kasper

1 Like
#6

Agreed. There are other ways to manage this other than turning on autocrlf (which has wreaked havoc on me in the past). Diffs are now full of noise I can’t get rid of. This is a terrible change to make without providing a toggle for it.

If I wanted to see things as Git renders them, I’d use Git directly. I use Sublime Merge for a more comfortable Git experience and this change misses that mark completely.

0 Likes
#7

I think that this new setting makes sense because enabling autocrlf and defining EOL normalization settings in .gitattributes are best practices — I also define .editorconfig settings in my repositories, hence the SM update didn’t result in odd diffs for me.

But it would probably be a good idea to expose the related repository settings via the SM interface, to simplify customizing settings like core.whitespace cr-at-eol from within SM, on a per-repository basis.

0 Likes
#8

I would also like to see resolution and/or clarification on this issue. It’s made reading diffs much more difficult.

  • It’s only appearing on certain files, even thought most, if not all, were composed on windows machines.
  • If I edit a file which isn’t showing them, on my Windows machine, and save it, SublimeMerge still doesn’t show <0x0d>
  • autocrlf is true, so according to djohnston’s reply, above, it suggests they should not be displayed.

Is there a way to rollback to previous Builds?

0 Likes
#9

G’day all,

Thanks for sharing your feedback - we’ve got some changes on the way that will address this issue.

In the meantime you can download Sublime Merge build 2083 (the previous stable build) at: https://download.sublimetext.com/sublime_merge_build_2083_x64_setup.exe

If you’d like to temporarily disable update checks until the fixes are available, you can perform the following steps (licensed users only):

  1. Open Sublime Merge
  2. Preferences > Edit Settings…
  3. Add the following line within the braces: “update_check”: false
  4. Save the file

I will update you again once the fixes are available.

Cheers,
- Dylan from Sublime HQ

0 Likes