On 03/10/2018 20:43, Christian Brabandt wrote:
>
> On Mi, 03 Okt 2018, Mike Williams wrote:
>
>> On 29/09/2018 10:50, Mike Williams wrote:
>>> On 25/09/2018 13:46, Mike Williams wrote:
>>>> Hi,
>>>>
>>>> Long term user, occasional poster.
>>>>
>>>> I occasionally use vim in powershell or cmd consoles. I have just
>>>> noticed that numbers on the keypad don't work. All the surrounding keys
>>>> work just fine, but the numbers don't. With -u NONE -UNONE and NumLock
>>>> on I get a lead byte of 0xce followed by 0xda (for 0) through 0xfe (for
>>>> 9) - each digit is offset by 4 from the previous one.
>>>>
>>>> With NumLock off there are no buffer updates for the number keys and
>>>> decimal point but various types of cursor/display updates occur (life's
>>>> too short to investigate 11 distinct actions with non-obvious effects).
>>>> The remaining keypad keys continue to insert expected characters.
>>>>
>>>> I rebuild 8.1.0000 and the same happens there. I could have sworn it
>>>> used to work. A quick google doesn't turn up anything obvious (some
>>>> discussion of console/keypad issues and WSL a year ago or so). Should
>>>> the keypad work in console vim?
>>>
>>> Small light bulb moment. As you all know I am sure with NumLock off the
>>> keypad acts as the cursor movement set. That just leaves my question of
>>> should the number pad with NumLock on result in digits being added to
>>> the buffer?
>>>
>>> Debugging the code in decode_key_event() I can see the keys being
>>> detected and handled as not being used with a modifier which results in
>>> mch_inchar() inserting K_NUL and an 8-bit character in the type ahead
>>> buffer. In fact based on the VirtKeyMap table any of the listed keys
>>> (some with modifiers) that produce an 8-bit character ends up inserting
>>> a character sequence and not being detected as a special key press.
>>>
>>> Removing the numbers from VirtKeyMap table -
>>>
>>> diff --git a/src/os_win32.c b/src/os_win32.c
>>> --- a/src/os_win32.c
>>> +++ b/src/os_win32.c
>>> @@ -908,7 +908,7 @@ static const struct
>>> { VK_SUBTRACT, TRUE,'J', 'J', 'J', 'J', }, /* keyp '-' */
>>> /* { VK_DIVIDE, TRUE,'N', 'N', 'N', 'N', }, keyp '/' */
>>> { VK_MULTIPLY, TRUE,'7', '7', '7', '7', }, /* keyp '*' */
>>> -
>>> +#if 0
>>> { VK_NUMPAD0,TRUE, '\332', '\333', '\334', '\335', },
>>> { VK_NUMPAD1,TRUE, '\336', '\337', '\340', '\341', },
>>> { VK_NUMPAD2,TRUE, '\342', '\343', '\344', '\345', },
>>> @@ -920,7 +920,7 @@ static const struct
>>> { VK_NUMPAD8,TRUE, '\372', '\373', '\374', '\375', },
>>> /* Sorry, out of number space! <negri>*/
>>> { VK_NUMPAD9,TRUE, '\376', '\377', '\377', '\367', },
>>> -
>>> +#endif
>>> };
>>>
>>>
>>> gets me the number keys working with NumLock on, but I have no idea on
>>> the effect with modifiers yet. I doubt this is the complete solution,
>>> but I don't know how the key handling works in VIM. Anyone willing to
>>> pick this up or tell me what needs doing?
>>
>> I believe have a fix for all this. It was a combination of poor code
>> and the change for 8.0.1371 which exposed it - chars with top bit set
>> are negative (at least with MSVC) which causes the wrong path in newer
>> code to be taken. Converting the 8bit chars to positive integer
>> constants appears to fix the issue and more - see attached diff against
>> 8.1.0450.
>>
>> This does raise the longer term issue of should console handling still
>> be emulating MS-DOS ANSI.SYS behaviour? Native console key handling
>> would remove the whole issue of key mapping - as noted in original code,
>> there aren't enough values for all keys and combinations!
>
> Does that perhaps also fix https://github.com/vim/vim/issues/3246 and
> https://github.com/vim/vim/issues/3423 ?
It does fix 3246. It seems to fix 3423 but it is not a method of using
VIM that I use so I am not 100% certain.
However this fix does break what 8.0.1371 kinda fixed - shift-ins
support. This means that fix was not the right one so I'll look into
that now I have a bit more knowledge of the area.
TTFN
Mike
--
It's easy to apply yourself, just use crazy glue!
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
