On 03/10/2018 19:44, Bram Moolenaar wrote:
>
> Mike Williams wrote:
>
>>>> 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!
>
> Thanks for taking the time to look into this. I'll include the patch.
>
> This is indeed very old code. But it appears to just work. It might be
> quite a bit of work to make something else, and then the question is if
> it's going to be better? So what will we gain?
The code seems error prone - occasional dives by various people to fix
isolated things seem to end up breaking other things. Mixing olde
MSDOS, current console, and VIM term sequences doesn't make it easy to
see what it should be doing. At this stage the handling of modifiers
does not seem to be working.
As noted elsewhere my change effectively undoes the fix for 8.0.1371 -
that seems to have broken more things than it fixed. I'll see what I
can do.
TTFN
Mike
--
A fool and his money are soon audited.
--
--
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.
