Re: [code] [textadept] Textadept 10.1

From: Alexander Misel <>
Date: Thu, 11 Oct 2018 07:08:25 +0000

I encountered the shift key problem too! But I didn't notice it.
From: Gabriel Dubatti <>
Sent: Monday, October 8, 2018 1:52
Subject: Re: [code] [textadept] Textadept 10.1

Hi Mitchell,

El 07/10/18 a las 14:09, Mitchell escribió:
Hi Gabriel,

On Fri, 5 Oct 2018, Gabriel Dubatti wrote:

Hi Mitchell,

El 05/10/2018 a las 17:06, Gabriel Dubatti escribió:
Hi Mitchell,

El 03/10/2018 a las 12:10, Gabriel Dubatti escribió:
Hi Mitchell,

El 03/10/2018 a las 10:58, Mitchell escribió:
Hi Gabriel,

On Wed, 3 Oct 2018, Gabriel Dubatti wrote:

Hi Mitchell,

El 01/10/2018 a las 10:52, Mitchell escribió:

Textadept 10.1 is released from


* Fixed view focus synchronization issues when dropping files into
* Fixed potential crash with non-UTF-8 bytes copy-pasted into non-UTF-8
* `spawn_proc:read()` correctly handles `\r\n` sequences.


* Added ability to save/restore persistent data during a reset event
  `events.RESET_BEFORE` and `events.RESET_AFTER`.
* Replaced `ui.find.find_in_files_filter` with
  `ui.find.find_in_files_filters` table for project-specific filters.
* Added Chinese localization.
* Updated to GTK 2.24.32 on Windows, which fixes a number of various


TA10.1 in working fine for me in Linux but in Windows 7 64 bits it does
read the shift key (tested with an empty .textadept folder with the .EXE
the zip and recompiling the code).

For example: pressing Ctrl+Shift+E is the same as pressing Ctrl+E
Entry" is run instead of "Select Command").

I compiled the nightly some days ago when you moved to GTK 2.24.32 and
some issues but didn't have the time to check it and return to 10.0.

Seems like in this version of GTK the keyboard is not working fine, at
for me, or some functions have changed.

Anyone else with the same issue?

I cannot verify in Win7 right now, but the Shift key works in Win10


I removed "caps_lock" from the if() to force to correct the case with or
without caps-lock pressed and seems to be working fine now.

local function keypress(code, shift, control, alt, meta, caps_lock)
  --print(code, M.KEYSYMS[code], shift, control, alt, meta, caps_lock)
  if (shift or control or alt or meta) and code < 256 then
    code = string[shift and 'upper' or 'lower'](string.char(code)):byte()

I'll start using this version and see if something else breaks.



The change I made works fine for letters but not for symbols....

For some keys like [,] ([<] when SHIFT is pressed) it works fine for typing
but when CONTROL is pressed the SHIFT modification is discarded in the code
and I get CONTROL +[,] regardless of the state of the SHIFT key.

Others keys like ['] return complex code values like 65105 (0xFE51) when
CONTROL is pressed.



I found that the issue is related to the keyboard layout. If I change the
keyboard layout to "English" all codes seems to be OK (TA10.1).

I normally use the keyboard layout "English International" to be able to
generate some Spanish characters easily. That layout always worked fine for
me (TA10.0 included).

My keyboard is a Microsoft Natural Ergonomic 4000 (with English key caps).

Hope you can reproduce the issue on Win 10 with that layout.

It seems that the following GTK bug is the root of a problem:

It seems like the following fix is the root of the problem you're reporting:

I do not know enough to ascertain the best way to workaround this. Perhaps downgrading to the previous version of GTK for the time being. The fix above is a backport, and perhaps it's buggy.

If you're feeling adventurious, you could try building/installing GTK 2.24.31 via the instructions at You'd have to find a way to invoke the `pacman` command to use version 2.24.31 instead of the default 2.24.32. After you install .31, you can copy over all the dlls into a copy of a Textadept installation, overwriting its dlls. If that fixes the problem, then we can move ahead with a temporary downgrade.

When I have some time I'll try to put together a .31 build, but I'm pretty swamped right now that that might take a while.

Thanks for looking into this. I will study the changes and see if I can apply them manually.
Fortunately most of the key combinations work well with the change I made to core/keys.lua, so I think I'll continue using this version.


You are subscribed to
To change subscription settings, send an e-mail to
To unsubscribe, send an e-mail to
Received on Thu 11 Oct 2018 - 03:08:25 EDT

This archive was generated by hypermail 2.2.0 : Thu 11 Oct 2018 - 06:49:46 EDT