Hacker News Reader

> Very much about keyboards today is derived from strange quirks that were part of typewriters for very good reasons, but have never been properly reevaluated once they were converted to electronical keyboards. Of course, the main goal likely has been to minimize friction for those users that were already used to typing on a typewriter.

The original design is based on typewriters from the 1890s. Within a few decades the design constraints had already changed (hence e.g. the Dvorak layout, which is optimized for 1930s-style typewriters).

Anyhow, after the original typewriter and mid-20th-century teletype machines https://upload.wikimedia.org/wikipedia/commons/d/df/ASR-33_a..., the biggest influences of modern keyboards are designers at IBM and German bureaucrats from about 1980.

A number of features of the German DIN office equipment standards forced significant (frankly arbitrary and unnecessary) changes on anyone who wanted to keep selling computers in Germany.

There was a wide variety in computer keyboard designs up through the 80s, and then somewhere in the mid-to-late 80s the IBM 101-key layout became entrenched, and we’ve been stuck with it ever since, except for marginal niche alternatives.

There's a deep and complex answer to your point about Unicode code points, which is an interesting question to consider in light of the 1980s shift away from a terminal I/O paradigm.

The shallow response is the simple question: What are the Unicode code points for End, Calculator, F7, and Paste? These all have USB HID usages. (-:

> What are the Unicode code points for End, Calculator, F7, and Paste?

True; OTOH, there already are control characters such as `BS`, `DEL`, `BEL` and so on that also don't make all too much sense if you look at unicode just as a collection of glyphs. So, I personally would still maintain that allocating a couple of blocks for stuff like this wouldn't hurt that much.

Also, no one said that the HID specs could not describe a superset of unicode (e.g. transmit letters with a unicode prefix and control signals normally (or something similar)). It's just that the way things are now is about the worst case in a lot of ways.

But: As things work good enough, they likely won't change for a long time, so going on about it certainly is futile, too ;-)

Transmitting Unicode code points would, however, be a giant step backwards to the way that things used to be done, where our terminals had hardwired keyboard maps, that we had (if we were lucky enough to be even given the option by the manufacturer) to select on the terminals themselves, via setup menus or otherwise.

Whereas nowadays, everything is software-mappable. The actual hardware interface is agnostic as to the semantics of any particular key or chord. It effectively speaks entirely in terms of ISO 9995-1 key positions and a big bitmap. What any given key does is entirely software-programmable. (Apart from [Fn].) Even the nuttiness of the PC/AT backwards compatibility fake modifier keys is largely behind us.

We have regular keyboards with sometimes as many as 122 or 127 keys. The infamous "Space Cadet" keyboard had only 100 keys. Even the old 101-key U.S. PC/AT keyboard had more than that. We have gaming keyboards with even more keys, still, making use of the extensibility built into the protocol to have vendor-defined keys. (And there is even less of a relationship between those keys and Unicode than there are for the End, Calculator, F7, and Paste keys.)

Our applications know this, moreover. They don't only get told about characters. They know about key press and key release events, modifiers, and all sorts of special chords from [Alt]+[F4] to [Control]+[W].

We simply aren't using the old I-send-you-precomposed-characters terminal I/O paradigms in our input devices any more. Nor is that reflected in our WIMP user interfaces.

> I get more and more frustrated

Was it worth the suffering?