This both allows updating the captures from outside the text view (e.g. Find dialog) and it uses the correct captures if performing searches in multiple tabs with delayed replacements.
We pass the selected encoding to iconv which, for encodings with a //BOM modifier, will pass over the first 2-4 bytes.
If there is a byte order mark (that should be skipped) then we will not actually show the Unknown Encoding dialog, therefor we can safely assume that files that end up presenting the Unknown Encoding dialog will not have any byte order mark.
We already auto-hide them for majority of our scrollviews, but since they are hidden by default when using a trackpad, a few “new” scrollviews didn’t get this setting, and I hadn’t noticed.
Previously this database was loaded each time a file of unknown encoding was read, which could add a significant overhead when using “find in folder” with a large database and many files with unknown encoding.
There were two issues:
1. The window’s sheetParent property is cleared when sending orderOut: to the window so the NSModalResponse was never passed on, as we were sending it to nil.
2. The endSheet:returnCode: was using NSModalResponseCancel but the completion handler was actually testing for NSModalResponseAbort
This would be slowing down editing when using a high-latency file system, as the document’s display name would be fetched each time the window was updated.
We could call pop_callback before having pushed one because the latter is done after delay.
Also, when disabling observeSCMStatus we now destroy the SCM handle rather than only remove our callback (since we do not re-use the handle).
We could call pop_callback before having pushed one because the latter is done after delay.
The way we obtained a weak reference to ourself was also scoped incorrectly so our block effectively had a strong reference to self.
Lastly when disabling observeSCMStatus we should destroy the SCM handle rather than only remove our callback (since we do not re-use the handle).
Previously the save dialog would update encoding settings solely based on the path, but the user could set different line endings or character set for a file type (rather than extension).
This is because we remove the document record in dealloc (unregister), but at that time, the reference in the record (for the path/inode) has already been zeroed, so if a document is created for the same path/inode after the reference has been zeroed but before the record has been unregistered, we would use the zeroed reference as the result from documentWithPath:.
When running bundle commands we run a local event loop which means that we can receive events such as “document changed” while still waiting for the bundle command to finish.
When a document has a visible index then we scroll to this index, on bringing the document to front. This is not desired when we set the selection, since we basically do that to “scroll to this location”.
We do have a few patterns that match multiple lines, e.g. the XML plist.
The problem would happen if a document was opened using a multi-line “first line” match, but another grammar matched its extension. If this document changed location (same extension), it would switch to use the grammar that matched its extension.
This is incase our initializer fails, here dealloc is still called, but we didn’t get to add the callback so we should not try to remove it.
Why our initializer would fail is beyond me, but I see a few crashes from this (though all from the same user on 10.8.5).
The notification makes the text view update the visualIndex (saved as an extended attribute) so previously we would save the previous value for this attribute.
