ctrl+/ rings terminal bell even with "enable_audio_bell no" #4489
Comments
michaelsbradleyjr
changed the title
|
I suspect that Cocoa rings when this key combination is pressed. I tried to handle it in How to remove NSResponder, NSBeep useless responses? |
|
You probably need to implement performKeyEquivalent to get cocoa to not Implement it, call the super class method and return YES |
|
I handle it in [super performKeyEquivalent:event];
return YES;Another thing I noticed (without the above patch) ctrl+d However |
|
On Sun, Jan 09, 2022 at 08:04:00PM -0800, page-down wrote:
I handle it in `GLFWContentView`, if returns YES, it will not get the `ctrl`,`cmd` combination key press event. Does it mean that keypress events are not processed at this level and should not be terminated here (return yes)?
Are you saying, this patch kauses keyDown not be called?
```objc
[super performKeyEquivalent:event];
return YES;
```
Another thing I noticed (without the above patch)
ctrl+d
```text
Press: native_key: 0x2 (d) ... doCommandBySelector: (deleteForward:)
```
However `ctrl+/` does not have any `doCommandBySelector`.
And it looks like ctrl+d should not call `(deleteForward:)`.
It doesnt matter, none of Cocoa's builtin actions actually do anything in kitty,
other than insertText.
|
Yes, only the
Ok, as long as there are no performance issues, then it can be ignored. |
|
Yes, performKeyEquivalent is called first, so you would need to |
|
Thanks. // performKeyEquivalent:
[self keyDown:event]; return YES;Then I noticed that the keys still made a sound. Emitted from a function call in keyDown. // keyDown:
[self interpretKeyEvents:[NSArray arrayWithObject:event]];
// ... sends the character input in eventArray to the system input manager
// for interpretation as text to insert or commands to perform ...If we want to implement this function and send key events to the menu. Then we need to handle only the shortcuts registered in the kitty and send all others to the menu or the system. Otherwise all the "global shortcuts" configured in the system will not work. I have not yet solved the problem, here are my notes. It does not make a sound in iTerm2, but this is a problem that exists in many other programs. It has been mentioned in numerous other open source project issues. some key combinations that make a sound: I have tested the following and it seems that none of them(in NSView, NSWindow, NSApp) will be called after implementation. https://developer.apple.com/documentation/appkit/nsresponder/1534197-noresponderfor - (void)noResponderFor: (SEL) selector
{
if (selector != @selector(keyDown:)) [super noResponderFor:selector];
}Workaround: |
|
why not simply override noResponderFor and if the event is a keyDown |
Yes, I edited the above before you replied. @interface GLFWContentView : NSView <NSTextInputClient>
@implementation GLFWContentView
@interface GLFWWindow : NSWindow
@implementation GLFWWindow
@interface GLFWApplication : NSApplication
@implementation GLFWApplicationAt this point |
|
In that case figure out what the last responder is using this technique https://stackoverflow.com/questions/4241416/how-to-inspect-the-responder-chain and see if you can override it there. |
|
You can also control the next responder by https://developer.apple.com/documentation/appkit/nsresponder/1528245-nextresponder?language=objc |
|
I think kitty use a very simple layout with almost nothing. I have implemented It looks like |
|
if its happening via interpretkeyevents then this technique should do |
|
Yes, I pulled out
That is no longer relevant to the responder chain.
glfw/cocoa_window.m GLFWContentView It looks like NSBeep first, then insert the text. Is there any useful information above? (I don't think so.) Take
This looks like a black box, poke around a bit and see what surprises pop up. |
|
I'm somewhat confused. ctrl+cmd_down will not insert text anyway. So it doesnt matter if inserttext is called or not, as long as keyDown is called. So it looks like to fix this what we need is a list of command handler functions and just insert empty stubs for them. |
|
Does this patch work: diff --git a/glfw/cocoa_window.m b/glfw/cocoa_window.m
index fb5b2cc8..86b2330a 100644
--- a/glfw/cocoa_window.m
+++ b/glfw/cocoa_window.m
@@ -1461,6 +1461,13 @@ - (instancetype)initWithGlfwWindow:(NSRect)contentRect
return self;
}
+- (BOOL)performKeyEquivalent:(NSEvent *)event {
+ if (![[NSApp mainMenu] performKeyEquivalent:event]) {
+ [self.contentView keyDown:event];
+ }
+ return YES;
+}
+
- (void) removeGLFWWindow
{
glfw_window = NULL; |
|
The above patch does not work, the shortcut still has sound. Sorry, I was misled by the comments in the original code. You are right, these key combinations have nothing to do with insert text. Does it mean that all modifier key combinations should not call |
|
On Mon, Jan 10, 2022 at 04:28:37AM -0800, page-down wrote:
The above patch does not work, the shortcut still has sound.
Sorry, I was misled by the comments in the original code. You are right, these key combinations have nothing to do with insert text.
Does it mean that all modifier key combinations should not call `interpretKeyEvents`?
There is no way to know which ones generate text and which dont. So it
is safer to call it unconditionally and instead implement the various
commands like moveDown etc as stubs.
|
|
Thanks for the explanation, it is indeed true that it needs to be sent unconditionally. I'm also a little confused. To sum up
Is this what you describe? Here are the example cases
I wonder if I misunderstood and if there is a better way to do this. |
|
On Mon, Jan 10, 2022 at 05:01:46AM -0800, page-down wrote:
Thanks for the explanation, it is indeed true that it needs to be sent unconditionally.
I'm also a little confused.
To sum up
- Do not implement `performKeyEquivalent` to let each shortcut call individual command function.
- Implement functions for each command, which cannot be empty stubs, to get the key events and send them. (Is it possible to get the key events in these functions?) e.g. moveDown -> send ctrl+cmd+down
No if interpretyKeyEvents is causing the individual commands to be
called, then they can be empty stubs. interpretkeyEvents is called from
keyDown, so it doesnt matter what happens in it, keyDown is already
called.
|
|
If the commands are being called by something else, then we need to find out what that something is first, and then figure what to do based on that. |
|
And looking at the call stack you posted, the something else is NSTextInputContent. The beep is coming from the system text input context (NSTextInputContext) in its doCommandBySelector method. There is no way of overriding that. So basically, there is no solution to this. As usual, cocoa is inadequate. So given that I think this is a CANTFIX, complain to Apple. |
|
Yes, if there is no way to control this behavior, then it is not fixable.
It looks like the only way to avoid this is to not send to I did the following test and there is no sound anymore. const bool process_text = (keycode != 0x7d /* down */ ) && ... ; |
|
On Mon, Jan 10, 2022 at 08:09:20AM -0800, page-down wrote:
Yes, if there is no way to control this behavior, then it is not fixable.
> ctrl+cmd_down will not insert text anyway. So it doesnt matter if inserttext is called or not, as long as keyDown is called.
It looks like the only way to avoid this is to not send to `NSTextInputContext`. So when pressing `ctrl+cmd+down`, is it possible to set `process_text` to false and it doesn't seem to need `insert text`?
I did the following test and there is no sound anymore.
```objc
const bool process_text = (keycode != 0x7d /* down */ ) && ... ;
```
yes, but there is no way to know what key combinations will cause this.
Especially since users can override these in macos system preferences.
|
I have looked through the related issues from various open source projects and pressed almost all the key combinations.
The above basically covers all the cases where sound is present. I think it's good enough. EDIT:
I forgot that you can use "InsertText" in keybindings, which does lose text. You are right, it is not appropriate to do that. |
|
On Mon, Jan 10, 2022 at 08:26:21AM -0800, page-down wrote:
> yes, but there is no way to know what key combinations will cause this.
> Especially since users can override these in macos system preferences.
I have looked through the related issues from various open source projects and pressed almost all the key combinations.
For now, I have not found any other *default* combinations.
- ctrl+cmd+down
- ctrl+cmd+left
- ctrl+cmd+right
- ctrl+/
The above basically covers all the cases where sound is present. I think it's good enough.
The problem isn't figuring out the default key combinations. The problem
is what happens if one of these key combinations actually produces text.
Either because the use remapped them or the user is using some IME
engine that remaps them. Then in order to avoid the beep you end up
losing text.
|
Thanks for looking into this, @kovidgoyal and @page-down. In its Profile -> Terminal preferences, iTerm2 has this:
And with those settings, here's what happens when I press Screen.Recording.2022-01-10.at.10.26.21.movI realize iTerm2 and Kitty are completely different projects/programs, but it seems possible to intercept/silence it on macOS, at least in the cases of some key combos. |
|
On Mon, Jan 10, 2022 at 08:30:16AM -0800, Michael Bradley wrote:
I realize iTerm2 and Kitty are completely different projects/programs, but it seems possible to intercept/silence it at least in some key combo cases.
It's definitely possible but it is not possible to do it *robustly*. I
am not willing to potentially break text input just to silence a bell.
|
Fair enough. Sucks for me since I'm really loving Kitty but the beeps for one of my all time most pressed key combos in Emacs ( In any case, Kitty is an awesome project – thank you for it and all your hard work on it! |
|
~/Library/KeyBindings/DefaultKeyBinding.dict Restart kitty and you will find no more sound. |
|
I take a second look at the other open source projects. https://github.com/macvim-dev/macvim/blob/master/src/MacVim/MMAppController.m See https://github.com/macvim-dev/macvim/blob/master/src/MacVim/KeyBinding.plist Is this the right way to go? |
See: kovidgoyal/kitty#4489 (comment) For now can put a global workaround in ~/Library/KeyBindings/DefaultKeyBinding.dict ``` { "^/" = "noop:"; } ```
|
Isnt that basically the same as not calling interpretKeyEvents for In that very macvim file for instance there is a mention of ctrl+spacke+- |
|
Yes, the problem is the inability to override individual commands and replace them with stubs, which is what you already pointed out. Any other approaches that may cause text entry problems are not desirable. I think that's the conclusion, at least for now. |
ctrl+/ rings the terminal bell on macOS even with
enable_audio_bell noinkitty.conf. I have not tried it on Linux or other OS.The text was updated successfully, but these errors were encountered: