Re: [code] [textadept] Textadept 10.1

From: Mitchell <m.att.foicica.com>
Date: Fri, 12 Oct 2018 10:39:48 -0400 (EDT)

Hi Gabriel,

On Sun, 7 Oct 2018, Mitchell wrote:

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

Please download this win32gtk-2.24.31.zip[1], delete all .dll files in a copy of a Textadept installation, and copy over all .dll files in the zip's bin/ directory. Then see if you can reproduce the shift error and let me know.

Cheers,
Mitchell

[1]: https://foicica.com/textadept/download/win32gtk-2.24.31.zip

-- 
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 Fri 12 Oct 2018 - 10:39:48 EDT

This archive was generated by hypermail 2.2.0 : Sat 13 Oct 2018 - 06:29:22 EDT