A document which is loading is likely showing a modal dialog (encoding view) and calling sync_open will run a local event loop which may then lock up the UI.
Our excerpt would go to “end of line (with the CR)” rather than “begin of next line”, the latter though would be assumed when showing the match in the search results and cause a std::string exception.
Some users manually set their font to “Anonymous Pro”, “DejaVu Sans Mono”, or similar, where the created font will use a name without the spaces, so TextMate would consider this a failure and fallback to the system default (monospace) font.
This partially reverts commit 7e69201513.
On recent OS versions the /usr/bin/svn executable will prompt the user to install svn (if Xcode is not already installed) which can cause some user confusion, so we now avoid using /usr/bin/svn unless Xcode is installed.
This echoes commit 02a5747f89.
This is similar to commit 26e66b887a but this change affects reading files.
If we have a command that runs on `callback.document.did-save` and that command writes to another (open) document, TextMate would hang as the save completion handler is indirectly invoked by `dispatch_async(dispatch_get_main_queue(), …)` so the main queue is blocked throughout the execution of the completion handler, and this completion handler may run commands (`callback.document.did-save`) which means it runs a local event loop, and thus while running this event loop, a new event can arrive which tells TextMate that files have changed (and should be reloaded).
On 10.12 beta 3, when closing a window, the following exception is thrown:
Exception Name: NSInternalInconsistencyException
Description: <GutterView 0x7fa71c511150> has reached dealloc but still has a super view. Super views strongly reference there children, so this is being over-released, or has been over-released in the past.
Despite the mention of our GutterView instance being over-released, the actual problem is that we do not call super in our override of `removeFromSuperView`, where we nil out our partner view. A simple fix to avoid crashing would be just calling super in that method so that the view is marked as being removed; however, we can simplify the code and eliminate the need to override our super's method by using a weak reference instead and let ARC automatically handle the zeroing of our partner view.
After switching to a version of libressl compiled from source I am seeing crashes from BIO_new_mem_buf and PEM_read_bio_RSA_PUBKEY.
Also minor code touchups, no functional change.
Although the buffer is maintained by OakDocument, it makes sense to only allow access via an OakDocumentEditor instance, since the buffer only exist when the document is loaded (implied by the presence of an editor).
