This way we can have “Lookup Word” in the Source menu being a proxy for “lookup.documentation” and simply rendered as disabled when the current language have no such functionality.
When we update the text view frame we implicitly cause the gutter to refresh, which will ask for line records from the text view based on the selection, so we should ensure the selection is up-to-date before changing frame size.
This is to allow a bundle item to display another key than the one assigned to the item, e.g. when the bundle item is matched by a proxy item it should show that item’s key equivalent.
This will find (forwards or backwards) but preserve the existing selection.
Presently if the current selection is a zero-width selection (i.e. caret) then we still preserve it. This might not be desired, but one could imagine “extend selection” used with a regular expression which use a look-around assertion (resulting in zero-width matches).
On Mountain Lion the OS provides a colorWithCGColor: which tmColorWithCGColor: now wraps for (when available).
This fixes a warning when building with the 10.8 SDK.
Incase our index is out-of-date and we try to load and parse a grammar that does not exist on disk, we would get a grammar_t with a “null” root rule, this would later crash when trying to use the grammar.
As a simple fix we now ensure a dummy rule always exist.
This would cause a crash if the Bundles folder was a symbolic link (e.g. to DropBox) since we assumed the entry itself had entries (but only directory nodes have entries).
This closes issue #321.
We now load the image via NSImage and creates a CGImageRef from that (based on the current graphics context). This ensures we get the @2px version when on a HiDPI display.
When a bundle item’s title contains “«unit» / Selection” then the UI should only show either “«unit»” or “Selection” depending on whether or not the text view has selected text.
We filter out items that doesn’t have the current prefix and deselect current item if the user deletes the selection.
Some of this logic should probably be encapsulated by a filterPrefixString property added to OakChoiceMenu. This will also avoid the visual flash which arise when filtering the menu and selection changes (since we do one redraw w/o any items selected).
Since we overload performKeyEquivalent: for the main menu to not search the bundle menus, there should no longer be a need to try and prevent the system from interpreting key equivalents for bundle menu items.
This is done using an alert with an accessory view. Not the best user experience, but given how rarely the user interacts with this, I wasn’t really in the mood to spend a lot of time on this part now (can always be improved later).
Closes issue #200.
This is specifically to find the actions bound to modifier + [, {, }, and ] before finding the actions bound to modifier + numbers, since on some keyboards, modifier + number results in one of the brace characters.
This should address issue #374 (although this isn’t a fix per se for the underlying problem of having some key maps result in duplicate keys in the menus).
For example Xcode projects now have their target (URL) set to xcodeproject://path/to/project/file which would cause Show Package Contents to not work, as it expected a file URL.
