Re: [code] [textadept] Textadept 10.1

From: Gabriel Dubatti <gdubatti.att.gmail.com>
Date: Fri, 5 Oct 2018 18:00:46 -0300

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.

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 Fri 05 Oct 2018 - 17:00:46 EDT

This archive was generated by hypermail 2.2.0 : Sat 06 Oct 2018 - 06:35:03 EDT