Not using any new C++17 (draft) features, but we may want to use std::variant as soon as it becomes available (as we currently use boost::variant), although std::variant will be a library feature.
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.
This is an optimization but it also fixes a crash when CFCharacterSetIsLongCharacterMember is called with extremely large values.
One crash report shows the input being 0x1001DEBC, which is not valid UTF-32, could perhaps be the result of loading a garbage file, so it might make sense to perform some range checks when the user selects to load a file using a UTF encoding.
It could also be command output or possibly copy/paste.
Previously we would save 60 seconds after a change, but successive changes would not bump the timer, and we had a timer per pasteboard, so changing both the find and replace pasteboard would schedule two save operations, even though they share context.
Now we save 30 seconds after any of the pasteboards were last changed.
Currently this bumping is limited to the Find dialog and happens when executing a search. Selecting from the Show Find History or subsequently using ⌘G, does not bump the date of the selected item (but probably should).
I see the following exception from macOS 10.12 users: Cannot update for observer <DocumentWindowController 0xhhh…> for the key path "selectedDocument.documentEdited" from <DocumentWindowController 0xhhh…>, most likely because the value for the key "selectedDocument" has changed without an appropriate KVO notification being sent. Check the KVO-compliance of the DocumentWindowController class.
There are two issues here, one is that double-clicking a result sends both “selection did change”, “did single click” and “did double click” messages, which all should potentially select the result in the document, but this does introduce a bit of overhead, although I think this is insignificant.
The other issue is that a “single click” or “selection did change” shouldn’t select in the document when the user is selecting multiple items, which is useful for the various Copy actions.
Based on diagnostic reports it would appear that the drag scroll timer can outlive the document. The timer is currently stopped on mouseUp: but this is probably not an event we should assume is always sent, for example if the application is made inactive while the mouse button is down, we may never see it being released.
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.
Inconveniencing all users with the “TextMate wants to access your contacts” dialog is not worth having the ability to contact users about their crash reports.
The parser takes time proportional with line length, so if doing a dozen quick edits on a very long line, we could have a dozen parsers running, making the CPU hot.
While it may break some unicode features (mainly mixing in text drawn right-to-left) it improves performance significantly (for files with long lines and no soft wrap).
