adding lineEndings UI in statusbar for documents

[sriram-dev]

Fix for #10106 and #10594
Tests Done

1. All tests under Brackets->Run Tests
2. jshint tests run from grunt jshint
3. Open a file, modify the Line ending option from existing(say CRLF) to other(say LF), save file. Close the file and reopen to notice that modified LineEnding is preserved.
   Let me know if any unit tests needs to be added for the change. I couldn't find any added for other status bar options available.

[sriram-dev]

Looks like travis failed because of CLA agreement. I had once signed long time back. Not sure if it was changed. I have re signed it now. Please restart if possible.

[sprintr]

@sriram-dev After changing line endings, it loses the cursor position. It would be nice if it retain cursor position.

[sriram-dev]

Yes. I will make one more commit to the PR to preserve cursor position and scroll position while modifying lineEndings.

[peterflynn]

You don't need this line -- the document model's text uses normalized line endings, so this is a no-ope anyway. Removing this line should fix the cursor/scroll position issues too.

[sriram-dev]

If we avoid this, the new lineEndings is not set to the existing file text. And document is left unmodified. With this change, file gets dirty(with new lineending added) and once we save, the new line endings is saved to file. It doesnt happen otherwise.

[peterflynn]

That's just a side-effect: a no-op change still marks the document dirty, and you can only save documents when they're dirty. If you remove this line, it will still work fine if you make any edits to the document (marking it dirty) before saving.

It does sound like this needs to be integrated with the dirty flag to have intuitive behavior, since it'd definitely be confusing if even explicitly saving wouldn't persist the change. I don't think this is the right way to achieve that though.

[sriram-dev]

Setting document.isDirty flag to true on Document.prototype.setLineEndings is a proper way ? It works.

[peterflynn]

One last thought: should toggling line endings mark the document as dirty? It could be confusing if a user toggles line endings, then closes the document, then discovers later that it still has the old line-ending type. OTOH, it could be architecturally a little tricky (or messy) to have this affect the dirty flag.

[marcelgerber]

If it marks the doc dirty, it should also be possible to undo using Ctrl-Z.

[peterflynn]

Making it undoable as @marcelgerber suggested is likely to be pretty tricky -- e.g. pushing some kind of custom entry onto the CodeMirror history stack. I don't feel we need to go that far, though.

One simple way we could mark it dirty: when changing line endings, set isDirty to true and also set a _lineEndingsDirty flag; then in _handleEditorChange(), change the expression to !editor._codeMirror.isClean() || this._lineEndingsDirty (and clear both flags in _markClean()).

[sriram-dev]

_handleEditorChange does not get triggered when lineEndings are changed currently. But just setting document.isDirty flag to true in setLineEndings and save(prompted otherwise on closing) afterwards preserve lineEndings.

[peterflynn]

@sriram-dev The _handleEditorChange() part is important: if you change line endings, type something, then undo, the editor will be marked clean again and you'll be unable to save the lineEndings change. (And then once you have the _handleEditorChange() part, the _markClean() part is important too, to turn off that behavior once the file is actually clean again).

[sriram-dev]

@peterflynn Got the reasoning now. Thanks for the clarification.

[marcelgerber]

The reason I suggested Ctrl-Z should also work for undoing this change is that I, and I'm certainly not the only one, often times get documents back into a clean state by pressing Ctrl-Z until it's clean again.
So I kind of expect that you can always get the document into a clean state by undoing several times.
If somebody relies on this, it could easily lead to confusion if this doesn't work with this (but only this) feature.

[sriram-dev]

I see currently none of the options in the status bar is affected by ctrl+z(ins/ovr, tab/spaces etc). Anyways can someone please confirm if we need it affected by ctrl+z or if the changes are fine for the PR ?

[marcelgerber]

The difference is, options like INS/OVR and tab/spaces don't directly change the document. They change how you interact with them, but they don't touch the content itself, while CRLF/LF does.
I also checked Notepad++ and yeah, you can undo CRLF/LF changes there.

[sriram-dev]

@marcelgerber Sounds like the right thing to do :)

[sriram-dev]

@peterflynn @marcelgerber If we want the line endings to be part of Ctrl+z, can you guys provide some pointers on the code changes needed for that ?

[sriram-dev]

Can someone please update on the next steps for this ?

[rhbecker]

I apologize if this is the wrong place to ask, but is there any chance this will be included in the next release?

[abose]

@sriram-dev @rhbecker
We apologize for the delay in response, i have tried to schedule this PR to release 1.4. It looks like we might not have enough bandwidth available to ship this pr through this release.
@rhbecker @sriram-dev Could you give a quick summary of the current state of the pr and the risks if this where to be shipped in 1.4?
@marcelgerber Could you help with this pr? Would this be safe to be picked up for 1.4?
Again, sorry for having to keep this pr waiting.

[marcelgerber]

Related: http://discuss.codemirror.net/t/custom-entries-in-undo-history/304
Let's see how far we get.

[marcelgerber]

This didn't quite work out well, but after a CM update, we could make use of the newly added option lineSeparator

[ficristo]

@sriram-dev @marcelgerber what is the status of this?

[ficristo]

Given this discussion the lineSeparator option is not really helpful and we will have to write our own mechanism for the undo.