plover
plover copied to clipboard
openstenoproject
Add NumPad keys as valid output characters
I'd like to be able to map a stroke to Alt+NumPad_64 and other Alt-codes, but Plover / the dictionary doesn't seem to support NumPad keys.
The root of my issue is a bug (?) with Plover, which is preventing me from writing the [ character with the Czech keyboard layout selected in Windows. In this layout, this character is produced by pressing AltGr+F (AltGr is a functionally identical key to Ctrl+Alt). On web pages and in programs where this key combination means something, the wanted [ character isn't produced, but a Ctrl+Alt+F key combination is produced instead. So I need a way to input the character directly, without involving the keyboard layout. This would be solved by being able to enter characters using Alt codes, hence the feature request.
If Plover does support NumPad keys, then my request is better documentation on the Dictionary Format page, which doesn't mention that as far as I'm aware.
Thanks for considering!
Just looking through the code, I think the number pad keys are:
kp_0 through kp_9
So for your example, {#alt_r(kp_6 kp_4)} should work.
If this works for you, we should update the documentation before closing the issue. Thanks.
Really, if Plover is not doing the right thing for outputting [, then we should fix that. Is that an official layout? What's the entry you used? What the output you're getting instead of [?
@morinted I tried creating an entry for the suggested mapping. I'm using AutoHotkey's key history to check which key strokes are being sent to the system and I checked it after pressing the stroke and everything seems to have gone well (the correct keys are being simulated), but to my surprise, the expected output (Alt+64 is the @ symbol) isn't there. Very odd. This might have something to do with the fact that I'm currently using Plover via remote desktop, though. I'll have to try when I'm physically at my PC.
@benoit-pierre The Czech layout, and many international layouts, have the number row occupied by symbols with diacritic signs (in Czech it's the symbols ěščřžýáíé). The numbers are written with the Shift key. The symbols that are there on the English keyboard now needed a different way of being written, so the creators of the official Czech layout opted to put them behind the AltGr key, so e.g. AltGr+/ is *. From what I can tell, the way Plover outputs symbols is by looking for a stroke in the current keyboard layout and simulating that stroke.
In the Czech layout, the stroke for [ just so happens to be AltGr+F, which is functionally identical to Ctrl+Alt+F. This works fine sometimes, but becomes a problem if the program you're in has an action associated with that hotkey. It's worth noting that this isn't technically a problem of Plover per se, this also happens if you want to write the character in the Czech layout without using Plover. It would just be nice to have a work-around.
I'd assume, if you tried to write a character that wasn't on the keyboard, Plover would automatically use the alt code?
Actually, I think conversion of alt-codes into text might be done after AutoHotkey gets to see the keystrokes. So if you're making Plover send alt codes to write a character, you would have to type it into some programme and see what comes out there. You might want to test it in several text editors and maybe also a web browser since support for alt codes can vary between applications.
And based on the mention of alt codes and the later mention of AutoHotkey, I think you should mention in the description that you're running Plover on Windows.
@SeaLiteral Yes, thanks for clarifying, I am running Plover on Windows.
I'd assume, if you tried to write a character that wasn't on the keyboard, Plover would automatically use the alt code?
The character actually is on the keyboard, it's just hidden behind the AltGr key. Plover seems to know this and simulates pressing the AltGr key to produce this character.
[…] support for alt codes can vary between applications.
I'm quite convinced that Alt codes are a feature of the OS rather than having to be supported by the application. I could be wrong of course, but I've never seen an application that didn't support Alt codes.
Since creating the issue, I've worked around it by creating a stroke to switch keyboard layouts and I'm using the English (US) layout when using Plover.
I think I remember Notepad not supporting alt codes. And some games won't even accept alt gr. Or writing any non-English character. I don't remember if IDLE (a Python IDE) supports alt codes, but it definitely doesn't handle emoji.
This is a problem with Windows, not Plover.
https://answers.microsoft.com/en-us/windows/forum/windows_7-desktop/alt-gr-is-equal-to-ctrl-alt-gr/6db594d4-6ffd-4506-87c1-8216dd7e41e7
It should be possible to configure Plover to never use AltGr, but that would only be a workaround. (the advantage is that it would probably work more of the time, the disadvantage is that it needs to send Unicode characters more frequently)
Making Plover an IME would work too.
