This was required when we linked each framework as its own thing, which we do not do anymore, and if we do go back to this system, we can simply have symbols public by default.
Several places already used ‘token’ as the name for the result from NSNotificationCenter’s addObserver:… so this change is to be consistent.
While ‘token’ is less meaningful than ‘observerId’, the variable is only used with NSNotificationCenter API where the context makes it clear.
This is because OakDocumentView is not in the view hierarchy and it obtains the theme via settings_t, so there is no way to notify about theme changes.
Previously we stored discontinuous selections as a newline-delimited string, and therefore the individual fragments could not contain any newlines.
Now that we use NSPasteboard’s multi-string support, we no longer have this limitation.
I was using the clipboard history as a testbed for CoreData but my conclusion is that it was not a good fit, and with the API we used now being deprecated, and the clipboard history needing various improvements, it’s easier just to replace the CoreData backend with sqlite3 and offers us more flexibility going forward.
With this re-implementation there is now support for storing multiple strings on the clipboard and the check to see if other applications changed the clipboard should work better (it appears that if an application is changing the clipboard while TextMate is active, sometimes the NSPasteboard’s changeCount is not updated).
It now also stores the history item’s row ID on the pasteboard, so if we select the non-latest history item and relaunch TextMate, it will no longer treat the current item on the pasteboard as a new item.
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:.
