Why should -[NSTextInputClient doCommandBySelector:] not pass the event up the responder chain?

Question

A text view should not forward uninvokable commands up the responder chain, the docs say for -[NSTextInputClient doCommandBySelector:]:

If aSelector cannot be invoked, then doCommandBySelector: should not pass this message up the responder chain. NSResponder also implements this method, and it does forward uninvokable commands up the responder chain, but a text view should not. A text view implementing the NSTextInputClient protocol inherits from NSView, which inherits from NSResponder, so your implementation of this method will override the one in NSResponder. It should not call super.

The last sentence does not clarify but only rephrase how things are set up if my text understanding does not fail me.

So there basically just is a prescription: "a text view should not". Period.

But why?

I can fathom a case where you want a text view not react to any/all NSResponder methods but delegate these up to its view controller, for example. Would this cause trouble? Is this just advice to keep text view behavior consistent across macOS apps?

Answer 1

From The Key-Input Message Sequence:

If the first responder is a text view, the key event enters the text system. The key window sends the text view a keyDown: message with the event as its argument. The keyDown: method passes the event to handleEvent:, which sends the character input to the input context for key binding and interpretation. In response, the input context sends either insertText:replacementRange:, setMarkedText:selectedRange:replacementRange:, or doCommandBySelector: to the text view.

It wouldn't be correct if the text view handles the key event and the scroll view or some other view receives the doCommandBySelector: message. You are not allowed to send doCommandBySelector: to super but you are allowed to send the selector to a delegate.