search

brackets-archive / bracketsIssues

Archive of issues in brackets.
0 stars 0 forks source link

[CLOSED] Files with CRLF are rewritten to LF when saved #168

Open core-ai-bot opened 3 years ago

core-ai-bot commented 3 years ago

Issue by peterflynn Saturday Jan 28, 2012 at 01:57 GMT Originally opened as https://github.com/adobe/brackets/issues/164

Steps:

  1. Open a file containing CRLF line endings (if you are using GitHub on Windows, all your files will start out this way)
  2. Make any edit & save
  3. Inspect the file e.g. in a hex editor

Result: All line endings in the entire file are now LFs

Expected: We shouldn't rewrite the line endings throughout the file. For newly inserted lines, we should auto-detect whether to use LF or CRLF based on the existing content of the file (if the file is blank, e.g. from File > New, we should choose based on the current platform).

Although this technically isn't a Windows-only bug, Mac-centric developers are unlikely to notice it (unless their team also includes Windows users).

Marking medium priority because it is a bit of a pain for dogfooding -- it means Git will issue a warning every single time you try to stage any changes (because it automatically makes line endings match the platform, it's not expecting line endings that don't match).

core-ai-bot commented 3 years ago

Comment by peterflynn Saturday Jan 28, 2012 at 01:59 GMT

Looks like a CodeMirror issue: I debugged into EditorManager._createEditor() and the string we read in has CRLF; but the instant we hand it to CodeMirror, its getValue() starts returning a string with only LF.

However, we can probably fix this without patching CodeMirror: e.g. we could decide which line endings we think the file should have, save that on the Document, and then rewrite them to the desired value each time we save. The only downside to this would be that we wouldn't preserve mixed line endings within one file... but people should be thanking us for doing that anyway ;-)

core-ai-bot commented 3 years ago

Comment by joelrbrandt Monday Jan 30, 2012 at 22:17 GMT

@peterflynn there's a related-in-topic-area bug for CRLF in Mac -- #119. This was originally low-priority while we were just working on mac, but now it's probably a higher priority.

core-ai-bot commented 3 years ago

Comment by jlondon Friday Feb 03, 2012 at 06:43 GMT

Recommending for Sprint 4 Bug Fix Story

core-ai-bot commented 3 years ago

Comment by peterflynn Tuesday Feb 14, 2012 at 19:07 GMT

Definitely CodeMirror: in setValue(), it essentially discards all line-ending information since only the array of text lines (via string.split()) is stored, not the original text. Then in getValue() the lines are Array.join()'ed with a hardcoded "\n".

core-ai-bot commented 3 years ago

Comment by peterflynn Wednesday Feb 15, 2012 at 21:31 GMT

Closing since I already satisfied myself of this fix

core-ai-bot commented 3 years ago

Comment by basarat Wednesday Sep 09, 2015 at 07:31 GMT

The only downside to this would be that we wouldn't preserve mixed line endings within one file... but people should be thanking us for doing that anyway

Is this still the current behavior? What if one opens an empty file on windows and presses and enter key. I suspect brackets would have \n whereas if the user did the same in notepad they would have \r\n > which is what a git checkout would have given them for an empty file.

Either way I am fine with the proposed solution ... just curious :rose: