Previously we would read these values when creating the OakTextView so they would be used for all document types. Now they are re-read each time we change document, so it’s possible to have different fonts for different documents based on type or location.
The stringForType: method seems unable to handle this type, as a textClipping file dragged to TextMate (on 10.11) will result in a string with null bytes, presumably because the data was UTF-16 but interpreted as ASCII / MacRoman.
This change mirrors what we did for services in commit 062a939189
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 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.
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.
With this change we only have OakTextView observe its current document.
This does mean that currently pre and post bundle actions are only executed for the selected document.
A document has both a virtual and an actual path. The virtual path is relevant e.g. when opening files via rmate, where we want to lookup file-type specific settings based on the remote path (filename) rather than the local temporary file. However, if there is no virtual path, we should fallback on the actual path, which broke when we made document_t a wrapper for OakDocument.
There is now a new logical_path getter which return the virtual path and fallback on the actual path.
Closestextmate/bugs#21
There are still methods that will fail (crash) when we lack a document, but everything involved with constructing and displaying the view should not work even without a placeholder document.
If we ask for a non-existing font then we may get back the system default font and as most users expect a monospaced font, we take extra steps to catch this situation and switch to the default monospaced font.
For example users that are currently using Menlo may get into this situation on macOS 10.12 where Menlo has been removed.
Furthermore, when no font name is configured we also use the system’s default fixed width font.
Prior to 10.8 we could not form weak references to NSWindowControllers and as a delegate’s superclass is unknown, and could very likely be a window controller, we could not use weak storage.
In general only the active view should respond to keys but we have the text view handle bundle items because they can provide actions that are not tied to text editing, for example “Build” or “Show SCM Actions”.
Ideally bundle items would (also) be handled by the window controller, but keyDown: is not commonly passed up the responder chain, so our window controller never sees any keys.
The way the system is designed is that the menu system will resolve keys (before the active view) and then send the menu item’s action up the responder chain, so views respond to actions rather than keys, but we cannot use this system for bundle items because it does not support multiple items with same key equivalent or scope selectors.
