On 09/07/2019, cho...@jtan.com <cho...@jtan.com> wrote: > Perhaps rather than whining that OpenBSD lacks some specific feature, those > who want it could write it? A novel idea, I know, but it IS specifically a > development platform and there are precisely zero restrictions. > > Or if you don't wish to start with code, at least try a tack such as "I > intend to write feature $foo and would like advice for how to go about it".
I intend to write feature "altnumd" and would like advice for how to go about it. To elaborate: Many older DOS/Windows users still have an old special character input method in muscle memory that goes back all the way to the IBM 5150[0]: Alt+Numpad[1]. Meaning, hold Alt, and then on the number pad, type a decimal code for a character in order to insert that character into the (originally BIOS-)keyboard buffer, from which it is off to the races, to be picked up by whoever is grabbing characters off the keyboard buffer. I'm explaining this, because AFAIK that feature has never existed on Unix-like OSes, and I think--corrections welcome--the BIOS isn't even involved when OpenBSD talks to the keyboard or vice versa. I am very aware of the Compose key support in X11, and this isn't about that. This isn't about inputting characters in a good or better way. This is about inputting characters in exactly THAT way (Alt+Numpad), "just like mammy used to". Alt+Numpad was originally a BIOS feature for the Single-Byte Character Set[2] DOS code pages[3] where--unlike in UTF-8 today--there was no difference between code units and code points[4]. Every one of the then at most 256 characters on the currently configured code page was at users' fingertips with Alt+0 thru Alt+255.[5] At least part of reimplementing Alt+Numpad support on OpenBSD (as 3rd-party software; I don't expect this to become an OS feature) should be possible in that these hotkey programs seem able to perform fairly arbitrary actions in response to configurable key sequences: <http://ports.su/x11/sxhkd>, <http://ports.su/x11/xbindkeys>. I have not yet explored this enough and not yet gotten them to respond to Alt+Numpad, but I suspect that may be possible. However, I don't have a sufficient understanding of the basics of OpenBSD/console/X11 keyboard support yet. I would like "altnumd" to work the same or as similar as possible on both console and X11. My very deficient understanding of OpenBSD non-BIOS keyboard support is this: I. keypresses on the physical (USB/PS2) keyboard. I think the actual keyboard has an internal microcontroller and small buffer, but I don't think that's accessible to write back to. --> II. Low-level OS keyboard device support. Presumably there's some sort of buffer there that could be written to, given permission? --> III. At some point things connect to console and/or X11, and then programs themselves have their buffers too. Is wscons always involved? Is that the lowest one can go and can that be written back to? I'm unsure. Essentially, after registering the keypress sequence, which existing hotkey programs seem up to, I would need to write something similar to a software keyboard emulator. Apparently there used to be this TIOCSTI thing that maybe could help, but this was removed for security reasons?[6] Is there an alternative? Also, it's not even quite clear to me where along the line from keyboard to program, the scan codes turn into code units/code points and characters. I.e., assuming the use of UTF-8 at the end of the day, once I've registered the right code for, say, the NOT character (Alt+170 on DOS CP437 or Alt+172 on Win/CP1252 and OpenBSD's old ISO-8859-1), once I've registered that, what goes into the buffer? 0xAA (170) or 0xAC (172), or UTF-8's ready-made 0xC2 0xAC (=U+00AC)? (Speaking of multiple bytes, a "stretch goal" might be the option to insert an entire string in response to an Alt code, but that's gravy and not the old muscle memory.) Yes, I seriously would like to do this if I can get good enough, from zero to not-quite-hero. Yes, I would very much appreciate help and any useful pointers. On-list, off-list, elsewhere, anything, from anyone. Ian PS: That said, nobody bet on me succeeding, unless you like losing money. [0] <https://en.wikipedia.org/wiki/IBM_Personal_Computer> [1] <https://en.wikipedia.org/wiki/Alt_code> [2] <https://en.wikipedia.org/wiki/SBCS> [3] <https://en.wikipedia.org/wiki/Code_page#DOS_code_pages> [4] <https://en.wikipedia.org/wiki/Character_encoding#Terminology>: "The compromise solution that was eventually found and developed into Unicode was to break the assumption (dating back to telegraph codes) that each character should always directly correspond to a particular sequence of bits. Instead, characters would first be mapped to a universal intermediate representation in the form of abstract numbers called __code points__. Code points would then be represented in a variety of ways and with various default numbers of bits per character (__code units__) depending on context. To encode code points higher than the length of the code unit, such as above 256 for 8-bit units, the solution was to implement variable-width encodings where an escape sequence would signal that subsequent bits should be parsed as a higher code point." [5] This was later extended, e.g. to bigger code pages and longer (or even alphanumeric) sequences, and while I don't want to support alphanumeric, I too would hope to support Alt+near-arbitrarily-long-nums, i.e. specifically I want to support users typing anything from Alt+0 through Alt+18446744073709551615, i.e. ull, i.e. unsigned long long int. (That's provided the sequence in question is included in a config file--.altnumrc?--listing sequences and the bytes to be inserted into the keyboard buffer in response to the respective sequence.) The emphasis would be on supporting existing Alt+0 thru Alt+255 muscle memory though. [6] <https://undeadly.org/cgi?action=article&sid=20170701132619>
