Windows version 11.4 (with German keyb. layout) comes seriously buggy

[ubegga]

Hey there,

I am having serious issues with v11.4 of TA.

1. When I open up TA for the first time and click anything in the Menu bar, the first time nothing happens except the dialog lights up as if it was hovered over and disappears. It takes a second click to open up the Menu dialogs.
2. The backslash can't be typed anymore. The command Alt + \ now behaves like Alt + Control + \ and instead of giving out a backslash it just changes the Wrapping Mode.

I re-downloaded v11.3 and everything is fine again. Can somebody confirm?

[orbitalquark]

Sorry to hear :(

1. I've noticed Windows tends to not-so-accurately report zip file extraction. "term.lua" is likely the last file being extracted and that's what Windows is reporting. There may be some finalization steps that are taking time to perform. Maybe anti-virus/anti-malware is also running. The extraction process takes a minute on my Windows 10 VM, but does not hang on "term.lua" or any file near the end.
2. I cannot reproduce this. Try temporarily moving your ~/.textadept folder somewhere else and relaunching Textadept in order to start with a clean user home.
3. Are you using the right alt by chance? I think GTK (the graphical toolkit Textadept uses) interprets right alt as Alt+Gr (a compose key), which can be processed as control + alt. Try left alt + .

[ubegga]

Hey,

1. Yes, it came up to my mind that this might be the anti-virus-software that checks all files. That's why indeed the last file is being shown as still being processed. That's why I deleted the first bullet point from my initial post. Sorry for the noise.
2. I did so. I have TA 11.3 and 11.4 extracted. The problem persists. v11.3 works fine. Only in v11.4 after a restart of TA I have to click two times on the dialogs. Ironically this doesn't occur when clicking File, Search, View or Help dialog. The bug only occurs when clicking either Edit, Tools or Buffer dialogs.
3. The problem is that only right Alt-key gives the backslash. Left Alt-key + \ doesn't work on Win with German KB-LO...

[orbitalquark]

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.

[ubegga]

I'll have to stay with 11.3 for now unfortunately then.

[mhwombat]

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)

[ubegga]

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.

[mhwombat]

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.

[mhwombat]

BTW, I'm in Ireland, and our keyboards have the Alt+Gr key.

[gabdub]

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.

[ubegga]

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.

[ubegga]

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...

[snoopy]

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?

[orbitalquark]

Textadept on Linux is using whatever version of GTK is installed on the user's machine.

[ousia]

@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.

[paaguti]

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...

[paaguti]

For reference, for the Qt version in Windows (Spanish keyboard) I have:

keys['ctrl+alt+\\'] = nil
keys['ctrl+alt+|'] = nil
keys['ctrl+alt+@'] = nil

[ousia]

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?

[rgieseke]

Could be your Linux window manager catching the combination before Textadept sees it?

[ousia]

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.

[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

[ousia]

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.

[rgieseke]

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.