`ctrl+cmd+???` keybinding oddness

[eric-hemasystems]

I'm working on migrating to Textadept v12. Currently doing this on Mac so the issue may be specific to that platform. If I create a keybinding of ctrl+??? it works fine. Example:

keys['ctrl+u'] = function()
  ui.dialogs.message{ text = 'Test' }
end

Same is true for cmd:

keys['cmd+u'] = function()
  ui.dialogs.message{ text = 'Test' }
end

Where it stops working is if I combine them:

keys['ctrl+cmd+u'] = function()
  ui.dialogs.message{ text = 'Test' }
end

But what is even more odd is that if I remove the above and activate the default action for that keybinding (which opens a list of files in the home directory) it works just fine. To add another round of oddness if I disable the menu with:

events.connect(events.INITIALIZED, function()
  textadept.menu.menubar = nil
end)

Now even the default action stops working. Overall summary:

• Keyboard shortcuts for both cmd and ctrl individually work fine.
• A keyboding with ctrl+cmd seems to not work unless the action is also in the menu. If the menu is disabled then effectively nothing is in the menu so none of the ctrl+cmd keybindings work.

I've tried this by starting with a blank ~/.textadept directory so it doesn't appear to be some other by-product of my customizations.

[orbitalquark]

Thanks for the report. I've always been annoyed at how Qt likes to gobble up menu keybindings, and that appears to be what's happening here. I thought that https://github.com/orbitalquark/textadept/commit/1a1bb1d17f7bab2d41e932079a5eaae3729e0d17 would fix it, but it doesn't look like it on macOS. I'll investigate this when I have some time and access to macOS.

[eric-hemasystems]

No problem and no hurry. I was able to figure out a "stupid but it works" workaround for now. Just add my custom actions to the menu even if I never plan to actually use the menu. Mac is the only platform where the menu is not in the way anyway so leaving it enabled on that platform.

BTW, just for additional info I did also have a keybinding of cmd+" that also did not work (although did once added to the menu) even though it doesn't follow the pattern above. Not sure if it's because I had to add the shift or what.

[orbitalquark]

I reverted the commit mentioned previously. It appears to fix the issue, and I haven't seen any ill side-effects. I wish I could remember why I made that commit...

This should be in the next nightly build.

[orbitalquark]

I found out why I made that commit: without it, menu items can no longer be selected. It has to do with Qt's internal logic: menu actions can only be triggered if they are enabled, but the disable-on-hide functionality happens before the check after click. Back to the drawing board... :(

I've reverted the revert: https://github.com/orbitalquark/textadept/commit/4db49a1c4c3f9598e937997b36c1fb82fc055fa3

[oOosys]

@orbitalquark You tackled an interesting point by reverting the revert: to know how to put enough documentation into the code to be able afterwards immediately to see what and why in first place is an art for itself.

I am missing such documentation overall in the Textadept code trying to guess the underlying concept (or lack of such a concept) from the source code alone. Best would be to generate the documentation from the documentation present in the code having both, the overview and the explanation exactly at that point in code the documentation is about.

I don't know yet a solution to the above problem which really works in any case. Probably there isn't any universal one as the spoken language is ambiguous and hard to master to a degree of full clarity of each sentence.

The best with what I came up until now is to look at the code after a longer time again and again and check it for sufficient documentation from which I can see immediately what the code is about, why this code, what was the main concept/idea behind it ... Knowing how to put an application together that works is already hard ... to document it in really understandable, clear and concise way even much, much harder ...

Handling keyboard input in a platform and keyboard independent way ... I suppose it's not possible without cutting the functionality down to very basic keys without coping with the Super and another keys. For example I still don't know how much keys could be hold down and recognized by the system ... the observed limit seems to be a maximum of three/four keys depending probably on many factors like the OS, the window manager, the keyboard hardware, the keyboard driver, ...

Still don't know how it comes that the cursor keys do not give a Lua event on my Linux Mint 21 Xfce system in the GTK version of Textadept 12.

[oOosys]

@eric-hemasystems : there is sure much more odd behavior to uncover if you dive deeper into the subject of keybindings. Some combinations don't propagate down to the windows of the application - depending on the settings and the overall design of the main Desktop interface by the OS and the used GUI library sitting between the application and the keyboard events.

On my Linux Mint 21 Xfce system with Textadept 12 GTK version pressing the cmd control key only combinations do not have any effect at all and pressing ctrl+cmd+u triggers the ctrl+u function ...

I don't have for example access to the usual input of Unicode characters using ctrl+shift+u available in mostly any other application on the system ... ctrl+shift+u remains without any effect in Textadept 12 GTK making it necessary to use an alternative way of Unicode input.

[orbitalquark]

@orbitalquark You tackled an interesting point by reverting the revert: to know how to put enough documentation into the code to be able afterwards immediately to see what and why in first place is an art for itself.

I am missing such documentation overall in the Textadept code trying to guess the underlying concept (or lack of such a concept) from the source code alone. Best would be to generate the documentation from the documentation present in the code having both, the overview and the explanation exactly at that point in code the documentation is about.

I don't know yet a solution to the above problem which really works in any case. Probably there isn't any universal one as the spoken language is ambiguous and hard to master to a degree of full clarity of each sentence.

I've found it's a combination of three things:

1. Readable source code
2. Code comments
3. Commit messages (which you can fairly easily get per line using git blame).

The revert of the revert happened because I didn't add enough information in the commit message. I added it this time so that if I ever have a question, I can look at the history and remember.

[oOosys]

@orbitalquark working with git surely helps, but I usually don't use git at all and the commit messages are not mirrored in the code, right?

[orbitalquark]

Revision control systems are a must in this day and age and they help to understand why changes are made over time. If commit messages were in code, it would become a spaghetti mess of unrelated comments with no semblance of evolution over time. This is off-topic to the issue at hand and I will not say any more about it. We can agree to disagree, and that's fine.

[oOosys]

@orbitalquark : Yes, agree to disagree is a nice way to achieve harmony based on respect for the reasons of the other. If I understand the reasons why someone else considers something from this and not other point of view it helps me to know when is it time to stop sharing the own one. In other words my motivation seems to be a fully another one as the motivation which has driven the creation and development of Textadept. In spite of this I think I will keep to try to as positively as possible contribute my 2 Cents here in hope it is welcome.

[orbitalquark]

This should now be fixed via https://github.com/orbitalquark/textadept/commit/4a871b2760a0d94f4856a70db6c6030fd70c2ad2.

[eric-hemasystems]

@orbitalquark - Finally getting around to trying this but unless I'm missing something I don't think it is fixed. BTW, let me know if you prefer me opening a new ticket vs appending to this one. Basically I'm getting the same behavior as before only now my workaround for putting it in the menu no longer works.

I thought perhaps it's something with my customization. So starting with a fresh .textadept config dir. I search the keys.lua file for a built-in command I can test with. ctrl+cmd+h seems like a good candidate. It also does not seem to activate. I did confirm if I manually choose it from the menu it does activate (the same is true of my custom commands).

One other thing I noticed is the quit menu item is disabled (but keyboard shortcut does work). Not sure if it's related but just looking at your previous fix it seems to relate to enabling/disabling menu items so thought it could be.

[eric-hemasystems]

Oh, and I am using 12.3 beta that was released a few weeks ago.

[orbitalquark]

Thanks for the report. I'll look into this again when I have some time. Sorry for the trouble :(

[orbitalquark]

After some investigation, I've determined that macOS eats any Ctrl+Cmd+Letter sequences not defined in the menu. If you want to define a Ctrl+Cmd+Letter keybinding, it must first exist in the menu. (It doesn't have to be accurate, that is, the binding does not have to ultimately be mapped to the same menu function; it just has to be defined in the menu so macOS knows not to eat it.) I don't know why macOS does this.

[eric-hemasystems]

I appreciate you looking into this!

My experience was that it's even worse. It eats keybindings even if they are in the menu. The built-in ctrl+cmd+h tested above was an example. It's in the menu by default but I cannot activate via key sequence. I can active via the menu.

In TextAdept 12.1 it works as you state. I have to put it in the menu to get it to work. But when I upgrade to 12.2 or 12.3 beta my experience is the key command does not work regardless of if it's in the menu or not.

[orbitalquark]

Does it happen for key sequences other than Ctrl+Cmd? I wonder if it’s related to the weird Ctrl+Cmd handling I ran into.

[orbitalquark]

Ugh, for some reason all of my testing was on a nightly build of 12.1 :( I'm going to have to revert https://github.com/orbitalquark/textadept/commit/4a871b2760a0d94f4856a70db6c6030fd70c2ad2. You're right that it's worse than I thought.

Sorry for this whole mess. I appreciate your patience very much.

[orbitalquark]

Okay, reverted in https://github.com/orbitalquark/textadept/commit/dfe7ea836bbc601671d7c50fb29f04133d5b5914. It should be in tonight's nightly build.

[eric-hemasystems]

BTW, just wanted to note that I had some time to update to 12.3 today and everything is back to working again. Thanks so much for your help on this. One day we can circle back to a way to have key bindings without them being in the menu for this but it's good enough for now. Thanks!