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.
Also, switch to use the new divider styles in most places. The remaining usage of the old "OakCreateLine" functions are in the OakChooser windows. These will be refactor for better dark mode support next.
This introduces the `OakBackgroundFillViewStyle` enum with styles that are dark mode aware and should lead to more consistent use between UI elements in the future. Also, convert OTVStatusBar and OFBHeaderView to use the new style enum.
Most of these layout changes are related to the common pattern we used to set constraints for "dividers", where one of the dividers is specified to be connected to both edges of its superview then setting the other dividers' constraints to have equal widths (e.g., @"H:|[divider(==divider2,==divider3)]"). On 10.12, this now appears to result in ambiguous layout. We can resolve it by connecting at least one of the edges for each divider to its superview.
Although this is actually deprecated in 10.10, new APIs are available in 10.9 and it will make addressing deprecation warnings when upgrading to 10.10 easier.
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.
It should only be necessary to overload this method (to return YES) when the system is unable to figure out by itself, that it should enable constraint-based layout for the window in which the view is placed.
Previously searching for something with a trailing newline would have the pop-out animation (image) include an extra empty line.
An issue is when only searching for a newline, currently this results in an empty image, so we need to special-case that.
Since we do not load documents before the user selects them, e.g. after session restore or when opening multiple documents, it makes sense to have both an isOpen and isLoaded property, the former means “is shown somewhere in the UI” and would make it appear (e.g. in file browser) with close button etc., whereas the latter means that data has been loaded from disk, and we can safely access the buffer.
This is only done for LRU tracking so it sort of makes sense to move this outside the document view itself (e.g. commit window and bundle editor does not require any LRU tracking).
