A view can only be drawn with the focused frame and title colors while it
is the current view, but a panel made of an outer view and an editable
field embedded in it has to look focused as a whole, whichever of the two
the keyboard is pointed at.
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Printable keys are withheld from keybindings while the user is typing in
a field, so that they end up as text. Decide that from the field that has
the focus rather than from the view a binding happens to be registered
for: a field can be embedded in another view, and that view's keys must
be withheld too, or its bindings would swallow the characters.
That makes it worth honouring KeybindOnEdit, which has been documented
but ignored ever since it was introduced. A field that sets it sees
printable keys offered to the keybindings first, and still gets them if
no binding handles them, which is what lets a view keep its keys until
the field has something to type into.
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
When a key matches several bindings of the same view, the first one wins;
when it matches several of the view's parent, the last one did.
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
