This was previously done because the function wasn’t available until 10.7, but since that is (now) our deployment target, there is no need to wrap the call.
Previously we would also retrieve settings for untitled documents, but we now rely on untitled documents getting their encoding settings from the choice made in the save panel.
We wrap the “update document” in an undo group, but if we already have an undo group at a higher level then our “end group” would be postponed to the root group, which would delay updating the document revision, and thus the revision we use as the disk revision would be wrong.
We workaround this by forcing the undo group to end and thus ignore the one at the higher level, which should be safe.
This would happen if the user manually saved one of the documents with replacements before invoking save all, since the wrong “did save” callback was called when trying to save an unmodified document.
This is only meant for when the document reloads content because the file was changed on disk. Long-term though, I think reloading document because of disk changes should be handled at a higher level.
When saving and the document needs to execute a command (e.g. callback.document.export) then we can no longer use our special run-loop mode, as command execution is now using queues, and queue dispatching is paused when running in a custom run-loop mode.
This resulted in missing proxy icon update e.g. when saving an untitled document over an existing one, as we would first set the path to the new location (and indirectly change the “is on disk” status without sending the proper notification).
Also skip checking for saved selection / visible index if there is no text in the buffer (since in this case, teh only valid values for seleciton / visible index are the default values).
This should be handled better, but previously we would crash due to filling the stack, so better to just immediately abort when we detect the problem, so that we get a better crash report and can see how widespread the issue is.
Previously if the file had been loaded as ASCII/UTF-8 and was changed on disk to something other than UTF-8, TextMate would go into infinite loop (retrying with UTF-8). It now uses the encoding classifier to find the most probable encoding (based on learned frequencies) falling back on ISO-8859-1, if there is no candidate.
Ideally it would bring up a warning, informing the user of the problem and allowing a manual correction of character set.
Fixes#1073.
