-
-
Notifications
You must be signed in to change notification settings - Fork 1.8k
Detect lua special dispatchers by reference #15215
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from 2 commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -144,6 +144,10 @@ static int hlBind(lua_State* L) { | |
| if (kb.catchAll && mgr->m_currentSubmap.empty()) | ||
| return Internal::configError(L, "hl.bind: catchall keybinds are only allowed in submaps."); | ||
|
|
||
| // detect a wrapped native-special dispatcher now, while the dispatcher function is still on the stack | ||
| // (luaL_ref below pops it). Lets the bind be tracked/released like a native pass/global/send_shortcut/mouse. | ||
| kb.wrapsSpecialDispatcher = Internal::dispatcherFunctionIsSpecial(L, -1); | ||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
When the bind target is a normal Lua function, Useful? React with 👍 / 👎.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. good point.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Even sounds like a common usecase to bind it like this and conditionally pass some ptt key only when gaming/fullscreen or something.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I mentioned in bullet 2 on commit 2 that this will not work on non-direct (e.g., nested) dispatcher binds. I'm not sure that this is a regression because If the direct Lua bind detection is too restrictive, we could add a Boolean somewhere on
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. well it has to either work or get ignored, we can't let pass just fuck up the key starte
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. To clarify, you're saying the nested dispatcher case is a requirement? In that case, do you approve of the argument to bind approach or not? Is there an alternative you would prefer? Another option might be to look at what it would mean to consider all bindings special in this way... tbh I'm responding right now because I can't sleep but I'm also too tired to think it through so I'll consider the implications for that tomorrow.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes, hl.dispatch with a pass inside a bind should work properly, or be ignored. It's fine to ignore it too because we have send_shortcut. Argument is not acceptable. This should be automatic. |
||
|
|
||
| int ref = luaL_ref(L, LUA_REGISTRYINDEX); | ||
| kb.handler = "__lua"; | ||
| kb.arg = std::to_string(ref); | ||
|
|
||
Uh oh!
There was an error while loading. Please reload this page.