Re: [code] [textadept] Textadept 10.1

From: Gabriel Dubatti <gdubatti.att.gmail.com>
Date: Fri, 5 Oct 2018 17:06:16 -0300

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

-- 
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 - 16:06:16 EDT

This archive was generated by hypermail 2.2.0 : Sat 06 Oct 2018 - 06:34:59 EDT