Re: [code] [textadept] Textadept 10.1

From: Gabriel Dubatti <gdubatti.att.gmail.com>
Date: Sun, 7 Oct 2018 14:52:46 -0300

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

Cheers,
Gabriel

-- 
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:52:46 EDT

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