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 ?
Best,
Christian
--
Wo Nachrichten fehlen, wachsen die Gerüchte.
-- Alberto Moravia
--
--
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.
