Do we still need to simulate the text editing keys of the Dandelion keyboard?

[rmkaplan]

In trying to understand why the WHEELSCROLL keyboard mappings and interrupts come and go in seemingly random ways, I discovered that there are settings in \MAIKOKEYBOARDS that get reinstalled (sometimes, TBD) when a MAKESYS or SYSOUT restarts (even if restarting on the same machine with the same physical keyboard as the system was saved on).

Some number of the characters associated with the different keys are in the 300 and 500 ranges (charactersets 1 and 2), which are undefined in XCCS (but not available in Unicode). But it wasn't at all obvious what they were encoding.

However, the file VIRTUALKEYBOARDS has additions to CHARACTERNAMES (LOADVARS 'CHARACTERNAMES 'VIRTUALKEYBOARDS) that correspond to the virtual images of the original Xerox keyboards. And there you find the names that are associated with these codes. For example, the character code 555 is associated with the name DOIT, and other codes have other text-editing identifiers (bold, notbold, font...).

TEDIT presumably would be sensitive to these character codes if they could be typed...but they can't. For things like bolding and italics, those interface signals should probably be replaced with more modern conventions like meta-b and meta-i.

Is it really worth preserving these old mappings?

[Anzus]

There’s probably room for a whole bunch of discussions related to keyboard mappings, as it affects Sedit too. And if we look at it from the standpoint of someone new to the environment the workflow sort of ends up in “you need to load VIRTUALKEYBOARDS and select the correct keyboard type if you want to edit” which seems broken if the goal is anything other than “hey this is a cool emulator for an old system”.

On Jun 1, 2021, at 10:12 PM, rmkaplan @.***> wrote:

In trying to understand why the WHEELSCROLL keyboard mappings and interrupts come and go in seemingly random ways, I discovered that there are settings in \MAIKOKEYBOARDS that get reinstalled (sometimes, TBD) when a MAKESYS or SYSOUT restarts (even if restarting on the same machine with the same physical keyboard as the system was saved on).

Some number of the characters associated with the different keys are in the 300 and 500 ranges (charactersets 1 and 2), which are undefined in XCCS (but not available in Unicode). But it wasn't at all obvious what they were encoding.

However, the file VIRTUALKEYBOARDS has additions to CHARACTERNAMES (LOADVARS 'CHARACTERNAMES 'VIRTUALKEYBOARDS) that correspond to the virtual images of the original Xerox keyboards. And there you find the names that are associated with these codes. For example, the character code 555 is associated with the name DOIT, and other codes have other text-editing identifiers (bold, notbold, font...).

TEDIT presumably would be sensitive to these character codes if they could be typed...but they can't. For things like bolding and italics, those interface signals should probably be replaced with more modern conventions like meta-b and meta-i.

Is it really worth preserving these old mappings?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/Interlisp/medley/issues/338, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACBP2DG4BUCBZEGCGAE5X3TTQWORDANCNFSM4553ZIOA.

[masinter]

I think there might be code for "chatserver" mode, where the cheyboard sends a stream of characters rather than keyaction transitions. This would be useful for headless (no X, no windows) applications, or even XMAS = style X-windows. There are a lot of projects that interact with each other; maybe it's time to try to sort them out.

[nbriggs]

There is a hard mapping between the bits in the keyboard bit vector and the key names, in \KEYNAMES -- you just count them off: "5" is the 0th bit, K5F, also known as SUN-OPEN, is the 111th bit. There are 7 16-bit words that all the keyboard keys, either physical or logically generated by the OS (say, from FN+xx), and the mouse buttons have to map onto.

The key known as PAD5 is also known as RIGHTKEY, DOIT, and PRTSC. Are the key action tables context dependent?

This should have nothing to do with whether or not there's a chat server that reads ASCII.

[nbriggs]

If "PAD5" is a problematic choice for the bit associated with the mouse-wheel/trackpad scrolling then we can pick something else -- but if we want it to do anything we have to pick some bit...

[rmkaplan]

PAD5 may only be problematic because it somehow arbitrarily mapped to some dandelion keyboard key, the maikokeyactions pretend that that key still exists, and separately there is something that causes the maikokeyactions to be restored from time to time.

If mappings that support those nonexistent keys are removed, the scrolling behavior may stabilize. That may be the right way of cleaning out a bunch of meaningless cruft.

But the scrolling behavior can also probably be stabilized just by putting the interrupts on the characters that the maikokeyactions are transmitting (i.e., stop fighting with history). Let 555 (DOIT) get the right-scroll interrupt.

It still remains to track down what triggers the reinstall of the maikokeyactions.

(Separately, in preparation for the eventual transition to internal Unicode, I think we can change the meta-character mask in LLKEY so that it translates the character not to character-set 1 (undefined in XCCS) but to character set E0, the private-use space in Unicode.)

On Jun 2, 2021, at 3:14 PM, Nick Briggs @.***> wrote:

If "PAD5" is a problematic choice for the bit associated with the mouse-wheel/trackpad scrolling then we can pick something else -- but if we want it to do anything we have to pick some bit...

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Interlisp/medley/issues/338#issuecomment-853417834, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQSTUJLP7T2JJX7TIJ5KC5DTQ2ULPANCNFSM4553ZIOA.

[nbriggs]

As it currently stands, I suspect the keyboard code is also mapping the "PRTSC" (print screen) key of a normal 104(?) key keyboard to that bit. I don't know that the initial mappings should be just "MAIKO" or incorporate more information about the system (X? 104-key keyboard? macbook keyboard? macbook european keyboard?) Currently the maiko X code has heuristics for assigning X keycodes to emulator key bits -- and I think it doesn't work well in the edge cases, but then it has no idea of what the physical keyboard it's working with looks like.