Re: [code] [textadept] Textadept 10.1

From: Mitchell <m.att.foicica.com>
Date: Sun, 7 Oct 2018 13:09:10 -0400 (EDT)

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ó:
>>>>>> Hi,
>>>>>>
>>>>>> Textadept 10.1 is released from https://foicica.com/textadept
>>>>>>
>>>>>> Bugfixes:
>>>>>>
>>>>>> * Fixed view focus synchronization issues when dropping files into
>>>>>> split
>>>>>> views.
>>>>>> * Fixed potential crash with non-UTF-8 bytes copy-pasted into non-UTF-8
>>>>>> buffer.
>>>>>> * `spawn_proc:read()` correctly handles `\r\n` sequences.
>>>>>>
>>>>>> Changes:
>>>>>>
>>>>>> * Added ability to save/restore persistent data during a reset event
>>>>>> via
>>>>>>   `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
>>>>>> GTK-related
>>>>>>   issues.
>>>>>>
>>>>>> Cheers,
>>>>>> Mitchell
>>>>>
>>>>> TA10.1 in working fine for me in Linux but in Windows 7 64 bits it does
>>>>> not
>>>>> read the shift key (tested with an empty .textadept folder with the .EXE
>>>>> from
>>>>> the zip and recompiling the code).
>>>>>
>>>>> For example: pressing Ctrl+Shift+E is the same as pressing Ctrl+E
>>>>> ("Command
>>>>> Entry" is run instead of "Select Command").
>>>>>
>>>>> I compiled the nightly some days ago when you moved to GTK 2.24.32 and
>>>>> got
>>>>> 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
>>>>> least
>>>>> 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
>>>> 64-bit.
>>>>
>>>> Cheers,
>>>> Mitchell
>>>
>>> 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()
>>>   end
>>>
>>> I'll start using this version and see if something else breaks.
>>>
>>> Cheers,
>>>
>>> Gabriel
>>
>> 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.
>>
>> Cheers,
>>
>> Gabriel
>
> 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: https://bugzilla.gnome.org/show_bug.cgi?id=165385

It seems like the following fix is the root of the problem you're reporting: https://gitlab.gnome.org/GNOME/gtk/commit/516c1ba159137462dbd7709801e9aa212b05f29c

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 https://www.gtk.org/download/windows.php. 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.

Cheers,
Mitchell

-- 
You are subscribed to code.att.foicica.com.
To change subscription settings, send an e-mail to code+help.att.foicica.com.
To unsubscribe, send an e-mail to code+unsubscribe.att.foicica.com.
Received on Sun 07 Oct 2018 - 13:09:10 EDT

This archive was generated by hypermail 2.2.0 : Mon 08 Oct 2018 - 06:38:13 EDT