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).
Ideally we would stay in the document framework, but the editor framework currently depends on our document framework and we want to introduce a OakDocumentEditor which encapsulates an editor and layout instance, so to avoid cyclic dependencies we are doing this as a new framework.
Once the last document dependencies have been removed from the editor framework, we can merge OakDocument and OakDocumentEditor.
That way, if we have a setting for [ templates/** ] and create a new file in the templates folder (via the file browser) these settings will apply.
Previously we used the folder without trailing slash which required making the file pattern something like [ templates{/**,} ].
Releasing the document observer will trigger a “document will delete” notification, and I am seeing a few crashes from this. I don’t see any theoretical problem with posting this from the destructor, as the object is still “live”, but let’s see if this change doesn’t fix the crashes.
