We now collapse if more than half the items are expanded, otherwise expand. Previously we relied on a property to track the collapsed/expanded state, which could be out of sync if the user manually changed the state for half the items, and we also needed to reset the state variables when updating search results.
Previously these were created on demand, but that meant loading the document in the UI thread. It also meant that multiple matches from same document would cause the document to be read for multiple times.
Furthermore, storing the match excerpt with the find::match_t type should allow for more flexibility, since we no longer need special logic in the table view delegate to load a subset of a document to get the display string, but will simply read it from the record.
A warning will be written to stderr when this happens. The user can provide -e/--preserve-escapes to disable the behavior.
Use -e0/--preserve-escapes=0 to suppress the warning.
Having an initial title that is different from what the user will see makes it harder for them to change the key equivalent, since they most know what this initial title is.
For more info see http://lists.macromates.com/textmate/2014-January/036949.html
When opening a folder we test against the ‘projectPath’ property (on already open window controllers), but this is not setup until we have an open document, and documents are opened using a background queue, so code running in the same event loop cycle as the session restore, will not get the proper value for this property.
The problem this fixes is: open /path/to/foo and quit TextMate. Now drag /path/to/foo to TextMate’s app icon. TextMate would first restore session (which includes /path/to/foo) and then open /path/to/foo (not seeing the restored folder as being /path/to/foo due to the uninitialized ‘projectPath’ property).
None of our layouts rely on the buttons not hugging their content, so we set the hugging priority so that we do not have to worry about wether or not the constraints capture this requirement.
Curiously, if only the hugging priority is set (to high) for the horizontal orientation then the find dialog can end up with an undesired layout, although all constraints are met.
Triggering a content reload will update the ‘enabled’ state of our buttons. These will be disabled if we have no actions set.
Of course the API should be so that the ‘enabled’ state is also updated when setting the actions, but I am being lazy here.
Since the menu item’s title can change (e.g. Word or Selection) and multiple menu items can have the same title (e.g. Tab Size » 4, Toggle Foldings at Level » 4) we store the menu item’s action + tag for the abbreviation.
Previously we would use highlight color if the table view was first responder. Now we use the highlight color if the cell’s background is set to NSBackgroundStyleDark, which then works when we use the cell in a table view which “shares focus” with a text or key equivalent field.
This is relevant when there is no filter string, as we then show a regular NSString which does not have an associated line break mode (unlike a string with marked up ranges).
These methods were deprecated in 10.7. Use `convertRectToScreen:` and `convertRectFromScreen:` instead. This is required for proper high resolution support.
These methods were deprecated in 10.7 and log warnings in the console when called. The documentation says to use `convertPointToBacking:` and `convertPointFromBacking:`, respectively, instead; however, these methods should not really be used in this case. We just want to store the top left position (point) of the OakChoiceMenu's frame in the OakDocumentView's coordinate systems so we can update its frame to the new position when OakDocumentView's bounds change. We do not need exact pixel alignment. The original choice to use the above deprecated methods was probably based on the use of `convertBaseToScreen:` and `convertScreenToBase:`, but these were also deprecated in 10.7. They can be replaced with the equivalent `convertRectToScreen:` and `convertRectFromScreen:`, respectively.
So instead, for this case, `convertRect:toView:` and `convertRect:fromView:` suffices and actually yields better tracking. (We could have used the corresponding "point" methods, as well, but we needed to convert the point to a NSRect to use `convertScreenFromRect:`, etc.)
With the original code, when the view bounds change, the position of the OakChoiceMenu would extend well below/above the placement of the caret.
