This is because the input context may open windows where it wants to handle arrow or number keys.
Unfortunately we can’t tell the system about our local key bindings, so we need to handle those ourself.
The system does not respect bindings for delete and arrow keys with control modifier set, so those we still handle.
We also handle multi-stroke key bindings, since handling successive key strokes should be done before menu keys, which the system doesn’t do (as we don’t call upon the system until keyDown:).
This avoids a state variable and the need for dealing with successive strokes in performKeyEquivalent: (to swallow bound keys before the main menu has a chance to handle it).
Rather than skip the field editor, regardless of which view it belongs to, we check if the first responder is the replace text field’s (current) field editor.
With NSTextInputClient conformance this feature works fairly well, though we currently do not pass events (that we have an action for) to the current input context, which e.g. means that arrow left/right cannot be used to move through the variations.
The documentation does say that subclasses shouldn’t overload it, we only call it from a single location, and here we may want to instead use the input context’s handleEvent:.
When VoiceOver users want to efficiently find an item in a list, they often go
through the items quickly, hearing just first few characters to decide whether
it is the item they want or whether it is positively not the one (in which case
they move to the next item). Therefore it is necessary for each row (item) of a
table to be worded in such a way for VoiceOver so that the most important piece
of information is read first, then followed by the less important piece of
information, etc.
E.g. for the file chooser, the most important piece of information about a file
is its file name. So we put that first for the VoiceOver user. If they are
unsure whether it is the right one (perhaps because there is more than one file
with the same name in different directories), then path to the file is read
after that.
Fixestextmate/bugs#10
Unfortunately, the text field is difficult to center properly (right/left arrow mode) since prior to 10.10 the popover's contents was set at inset (2, 2, 2, 2).
This was caused by performing regexp matching on a temporary string object and later accessing captures from the match (when the string object was out of scope).
Rather than extend the scope of the string object I rewrote the code to use Cocoa’s NSRegularExpression class so we avoid using C++ (and thus temporary objects).
The current version of mate is 2.10 which gets stored as 2.1 (when using a double), so TextMate would think the installed version was too old (though after updating it, a string would be stored, so it would only happen once).
This allowed framework headers to test whether they were build as part of the framework itself, or part of building something that depends on the framework.
Ideally though we should not need two different paths for those two cases, and we no longer have.
This seems more appropriate and given the small size and that the former is stack allocated, there is likely no real benefit in writing directly to the std::string that we return.
The button frame has been extended to the top/bottom of the tab bar and on Yosemite there are 3 pixels of padding to the right of the image (which are thus part of the button and hence clickable).
This will convert the event string to the proper glyphs and lookup function key glyphs in the font and set the proper glyph info attributes (if found).
