Dirty status change event

[flaub]

I'm currently approximating when a document is dirty by digging into the undo manager and checking if hasUndo() is true. It would be more convenient to have a 'changeDirty' event fire whenever the document changes from having edits since the last load.

It also appears that the 'change' event is firing out to embedder's code before the internal library has a chance to finish processing the event. My hack right now is to use a timer. How about having internal vs public events?
@Gissues:{"order":64.59627329192563,"status":"backlog"}

[paulb777]

I second the vote for a public 'isDirty' API for a document session.

@flaub - I'm not sure your hack works. What if a file save is done in the middle of a series of edits? The undo stack will no longer be in sync with dirty. My hack is to set dirty to true on an onchange event.

                    env.editor.getSession().on('change', function() {
                        session.dirty = true;
                    });

and clear it on file save.

Of course, this doesn't cover the case of making changes and undoing back to the last save.

[flaub]

Agreed that my approach probably doesn't cover all cases, however my hack involves doing a reset() on the undo manager whenever a file save happens. The downside with that is the user can't undo to a time before the last save.

[flaub]

Ugh, I really didn't mean to close this issue...

[iebuggy]

paulb777 's approach is the correct one. ACE already exposes enough functionality for this. I take it a step further and keep the original content around and then compare the current session's getValue() to the internally stored value. I then display an indicator to the user that the content has changed from the original. Notice how each of us took a different approach to this - that is the flexibility of ACE at work. To implement any one of our isdirty solutions in ACE itself would force one of our views onto future developers who would then take issue with the change.

[flaub]

iebuggy: If I understand correctly, that means every change (or keyboard event), you'll do a comparison of the entire text? That seems awfully inefficient. Will that scale very well? As the content grows, so will the loop required to compare.

[iebuggy]

For my needs, I'm not expecting more than a few KB of text and modern hardware can handle that without any issues. All of my tests show similar performance and one of my pet peeves is tying faster than the computer can process. So while I understand your concern, it is a non-issue. The first non-matching character will terminate the comparison anyway so the worst case is - someone on ancient hardware gets annoyed, goes to the start of the document, plants a random character there, and then resumes editing.

[fjakobs]

The undo manager could track this. It is basically just a check if then redo pointer is at the beginning of the undo stack.

[kagiasoldaccount]

I would like to see this implemented for three reasons:

1. The use case is common, to the point it's obligatory to any implementation that has a considerable post processing dependency i.e ajax, io, compilation etc.
2. It will prevent people from trying to guess how to do it, some of the suggestions posted here are woefully inefficient and others incorrect.
3. It will only increase the API by a single property.

[nightwing]

@kagia UndoManager now provides isClean() and markClean() methods.
you can do

editor.on("input", function() {
    // input is async event, which fires after any change events
    var isClean = editor.session.getUndoManager().isClean();
    // do something ...
})

[kagiasoldaccount]

@nightwing thanks!

[vanillajonathan]

The isClean() and markClean() methods are undocumented.

UndoManager.markClean() is undocumented #2719
UndoManager.isClean() is undocumented #2715