Open ubegga opened 2 years ago
Sorry to hear :(
Hey,
I've tried clicking on all sorts of menus, opening dialogs, etc., but I cannot trigger the behavior you describe :( I don't know what could be the matter. Textadept 11.4 switched from GTK 2 to GTK 3 since GTK 2 is EOL, so that could be causing some trouble, but I'm at a loss of what to do about it.
Regarding key bindings, it is a known issue that Textadept can behave poorly with non-US English keyboard layouts. I simply do not have the means to test it. Putting keys['ctrl+alt+\\'] = nil
should disable the wrapping key and hopefully re-enable being able to type the '\' key for you.
I'll have to stay with 11.3 for now unfortunately then.
I have a non-US keyboard (Irish). I haven't been able to replicate the backslash problem, but that may be because 1) I'm using the Irish layout, or 2) I'm on Linux, not Windows. But I may be able to help figure out what's going on, if you want to give version 11.4 another try.
Add the following code (temporarily!) to your init.lua. Launch Textadept from a DOS command prompt, power shell, or similar, and type the key combination that's behaving badly (in your case I guess that's AltGr + ). Let us know what DEBUG messages are printed. This will help us figure out exactly what keys Textadept is seeing, and how it interprets them.
--[[
TEMPORARY INVESTIGATION STUFF
--]]
events.connect(events.KEYPRESS, function(code, shift, control, alt, cmd, caps)
print("DEBUG 1", code, keys.KEYSYMS[code], shift, control, alt, cmd, caps)
if caps and (shift or control or alt or cmd) and code < 256 then
code = string[shift and 'upper' or 'lower'](string.char(code)):byte()
end
print("DEBUG 2", code)
local key = code >= 32 and code < 256 and string.char(code) or keys.KEYSYMS[code]
print("DEBUG 3", key)
if not key then
return
end
-- Since printable characters are uppercased, disable shift.
if shift and code >= 32 and code < 256 then
shift = false
end
print("DEBUG 4", shift)
-- For composed keys on macOS, ignore alt.
if OSX and alt and code < 256 then
alt = false
end
print("DEBUG 5", alt)
local key_seq = (control and CTRL or '')
.. (alt and ALT or '')
.. (cmd and OSX and CMD or '')
.. (shift and SHIFT or '')
.. key
print("DEBUG 6", key_seq)
return
end, 1)
Of course I'd stay with TA; I've been using it for at least 6yrs.
Anyway, I don't know how your code is supposed to work. I can't see any output (neither in the cmd-console in Admin mode, nor in TA's status bar, nor a new buffer). But I tried the following: my init.lua looks like this:
events.connect( events.KEYPRESS, function(code) ui.statusbar_text = code end)
In TA v11.3 I get following keypress-codes: Alt Gr = 65514 ß = 223 Alt Gr + ß ( = \ ) = 92
In TA v11.4 I get the same results. Except for the last one. Alt Gr + ß gives no result at all. It just switches wrapping modes. But when I use keys['ctrl+alt+\'] = nil like orbitalquark suggested then the backslash works. So it might be a conflict of different key shortcuts being bound to the same ASCII? code. Without searching for pictures, from what I know the (physical) US (so I think UK also) KB-LO is the only one without an "Alternate Graphic"-Key on the right side of the alpha-num-block, but another ALT-key instead. I'd wish users with a German, Polish, Russian, Asian or that kind of keyboard (lots of alternative symbols) could test the behavior of their KB input in v11.4.
Still the problem with the unclickable Edit, Tools and Buffer dialogs persists. Will double check on my laptop or somebody else's machine.
Ah, I guess the Windows version doesn't write to the console. Sorry about that. Can you try this:
events.connect(events.KEYPRESS, function(code, shift, control, alt, cmd, caps)
ui.print(code, keys.KEYSYMS[code], shift, control, alt, cmd, caps)
return
end, 1)
This will send the output to the message buffer.
BTW, I'm in Ireland, and our keyboards have the Alt+Gr key.
Just some info that might be useful.
I'm running a custom keyboard layout that I built using Microsoft Keyboard Layout Creator based on the "US International" standard layout.
As you can see in the image, the keyboard defines AltGr as an alias for "Ctrl+Alt".
When I press AltGr, with this layout I get 65507+65514=control+alt, but If I switch to "US International" (Windows+Space) I only get 65514=alt.
I got the same key codes in TA 11.3 (Win32 GTK2) and TA 11.4 (Win64 GTK3) from TA events and also from GTK directly in a popup dialog.
Ah, I guess the Windows version doesn't write to the console. Sorry about that. Can you try this:
events.connect(events.KEYPRESS, function(code, shift, control, alt, cmd, caps) ui.print(code, keys.KEYSYMS[code], shift, control, alt, cmd, caps) return end, 1)
This will send the output to the message buffer.
Works like a charm. Thanks for your effort.
And this is what I get:
TA v11.3:
(left) Alt:
65513 nil 5x false
(right) Alt Gr:
65507 nil false true 3x false
65514 nil **5x false**
Alt Gr + ß ( \ ):
92 nil **5x false**
\
TA 11.3 prints not only the code but also the backslash into the buffer. Note the last line above. TA 11.4 doesn't do that:
In TA v11.4:
(left) Alt:
65513 nil 5x false
(right) Alt Gr:
65507 nil false true 3x false
65514 nil **false true 3x false**
Alt Gr + ß ( \ ):
92 nil **false 2x true 2x false**
I hope that helps for now.
BTW, I'm in Ireland, and our keyboards have the Alt+Gr key.
I think you have a UK kb then. At least I wouldn't know of an Irish kb layout. But when you check gabdub's picture then you can see the Alt (not Alt Gr) key of the US kb on the right side. The results he gets also show that US kb has a different output.
Just some info that might be useful.
I'm running a custom keyboard layout that I built using Microsoft Keyboard Layout Creator based on the "US International" standard layout.
As you can see in the image, the keyboard defines AltGr as an alias for "Ctrl+Alt".
When I press AltGr, with this layout I get 65507+65514=control+alt, but If I switch to "US International" (Windows+Space) I only get 65514=alt.
I got the same key codes in TA 11.3 (Win32 GTK2) and TA 11.4 (Win64 GTK3) from TA events and also from GTK directly in a popup dialog.
Interesting indeed.
Your US right Alt gives 65514. My GER right Alt Gr gives 65507 + 65514. 65507 is my GER left CTRL while 65508 is my right CTRL. My GER left Alt gives 65513. And I guess that's the same output like US left ALT. Now when US right Alt is 65514 alone, then I wonder what 65514 on a German KB is supposed to be...
Sounds like a GTK issue. Specifically a Windows GTK issue. Apparently this has been broken in the past (https://bugs.launchpad.net/homebank/+bug/1958145).
Currently, TA is using a version that should not be affected by those bugs though: https://github.com/orbitalquark/textadept/blob/3d1edd40f90ad2a41d099bd877be0faa2538b649/src/Makefile#L452
@orbitalquark which GTK version is the Linux variant of TA using right now? Maybe using the same version for Windows could fix this?
Textadept on Linux is using whatever version of GTK is installed on the user's machine.
@ubegga,
backslash was a problem with a Spanish keyboard with beta versions for 11.4 (#212).
In my case, I had to add to my init.lua
configuration file:
keys['ctrl+alt+\\'] = nil -- disable problematic shortcut
So I got the backslash working again on Windows.
This also happens on a Spanish keyb and on the new "12.0_pre-alpha" based on QT. Works nicely on Linux, not yet tested on macOS. But Windows is a mess...
For reference, for the Qt version in Windows (Spanish keyboard) I have:
keys['ctrl+alt+\\'] = nil
keys['ctrl+alt+|'] = nil
keys['ctrl+alt+@'] = nil
In Linux, I don‘t know why I cannot get keys['ctrl+alt+o'] = io.recent_files
working.
I have even included it in init.lua
. This key combination works perfectly fine in Windows.
Any idea of what may be causing this issue?
Could be your Linux window manager catching the combination before Textadept sees it?
I cannot get key combinations with ctrl+alt
working.
I have tested ctrl+alt+i
, ctrl+alt+O
and even ctrl+alt+ω
.
I wonder whether my WM may be catching all ctrl+alt
key combinations.
Many thanks for your help and your reply, @rgieseke.
Are you using the Terminal/curses version or the GUI app? In the terminal 'alt' might be 'meta' (or super or whatever it is called).
See also here: https://orbitalquark.github.io/textadept/api.html#key-sequences
Are you using the Terminal/curses version or the GUI app?
GTK program.
In the terminal 'alt' might be 'meta' (or super or whatever it is called).
In the curses version, the combination doesn’t work using either key.
Then it must be your window manager, on a standard Ubuntu with the GTK GUI app it works. Terminal emulators can also be tricky, from textadept/modules/textadept.keys:
-- In general, bindings for the terminal version are the same as for Windows/Linux except:
--
-- * Most `Ctrl+Shift+`*`key`* combinations become `M-^`*`key`* since most terminals recognize
-- few, if any, `Ctrl+Shift` key sequences.
-- * Most `Ctrl+`*`symbol`* combinations become `M-`*`symbol`* since most terminals recognize
-- only a few `Ctrl` combinations with symbol keys.
-- * All `Ctrl+Alt+`*`key`* combinations become `M-`*`key`* except for word part movement
-- keys and those involving `PgDn` and `PgUp`. The former are not supported and the latter
-- use both modifier keys.
-- * `Ctrl+J` and `Ctrl+M` become `M-J` and `M-M`, respectively, because control sequences
-- involving the `J` and `M` keys are often interpreted as involving the Enter key.
Hey there,
I am having serious issues with v11.4 of TA.
I re-downloaded v11.3 and everything is fine again. Can somebody confirm?