medley
medley copied to clipboard
Interlisp
Problems with German keyboard
(reported by [email protected])
I downloaded the last version and it starts without problems, BUT I have trouble with the keyboard layout.
Of course, my Mac has a German keyboard, but I can switch to a US keyboard layout which looks rather familiar (see the attached screen shot of the keyboard viewer). The numbers and letters work, but many of the special character keys don't. I tried it with the following results:
first row
§ is null plusminus is null
- is null _ is null
= is ' (quote)
- is "
second row
[ is null { is null
] is = } is +
third row
; is null : is null
' is null " is null
\ is null | is null
fourth row
` is null ~ is null
, is ; < is :
. is .
is >
/ is - ? is leftarrow
I think the problem lies in a combination of what the Mac does, what X11/XQuartz does, what maiko does to try to address the X11 behavior, and what the Medley/Lisp code does. Since we last looked, XQuartz has had significant version upgrades -- I don't know whether this will have made a difference in the way that the keyboard handling is addressed/addressable at the XQuartz level.
Given that the German Mac keyboard has different physical keys, it is difficult for anyone here in the US to independently investigate or fix it. Below are the ABC-QWERTZ and default German keyboards you get on a US style physical keyboard -- they appear to be the same.
@rmkaplan writes in email: WHICHKEY.txt There might be a German keyboard mapping hanging around somewhere. But you might be able to roll your own.
The attached file WHICHKEY has function that tells you all the names that are associated with a key that you hold down. Once you know what Medley receives when you push a given key on the keyboard, you can use KEYACTION to assign whatever meaning you want to the up and down traansitions of that key.
So: (WHICHKEY) hold down a key within the next 3 seconds see the Medley synonyms for that key.
There is another function DOWNP that takes a keyname and tells you whether or not that particular key is depressed (after a 2 second lag).
Rainer Joswig added:
I use currently another macOS Lispm emulator, which uses the latest Xquartz as the X11 server and which successfully deals with a German keyboard.
It uses a special keyboard mapping and one can use the "dead" keys like ^, ´, `.
Another way one might also want explore is to use a keyboard mapping software on the Mac side. In the past I used 'Keyboard Maestro' for that in some applications.
i spent some time trying to see if there's anything about XQuartz on OS 10.13 and keyboard mappings. No luck so far.
From Guenther:
coming back to Rainer Joswig's remark that Medley runs on Mac OS 11, let me add that although I am still using Mac OS 10.13, I installed the latest update of XQuartz - which shows an incompatible behavior: All the keys I annotated with "null" in my first mail are simply non-existent, i.e. there is no reaction whatsoever in the terminal. Therefore, Ron's suggestion to fix the problem in Medley can't work, because those keys don't send any code. As already mentioned, this behavior is different from that of all other applications I tried. So, I think XQuartz ignores the MAc OS keyboard mapping, at least for Umlauts and alt-keys, and that seems to be independent of the Mac OS version.
XQuartz, Preferences, Input: [*] Follow system keyboard layout. XQuartz should have seen the German keyboard if that was the system default to start with, but when I switch back and forth between English and German, setting that causes xterm to see the difference. What it doesn't do is change the keycode transmitted, which is what Medley looks at.
From Prof. Dr. Goerz --
xev_event_keyboard.txt
From which we see that
keycode 18 is dead circumflex/degree keycode 35 is ssharp/question mark keycode 58 is less than/greater than
I think typing with non-US keyboards can't use the OS Locale-driven keyboard handling. It's a historical limitation of the architecture of being able to ask KEYDOWNP on a keyboard where there isn't a 1-1 mapping from keypresses and characters generated, not just for shift/control but for combined form / unicode normalization. We might be able to hook up an alternate Lisp device which accepts a stream of characters rather than a stream of keystrokes, if there isn't one already. It's hard to imagine what to do about TTYIN though.
I'm hoping we can make progress on getting Medley Online to work with international keyboards because WE control the configuration of the X-server and VNC and MAIKO and Lisp code.
We still don't have any control over what the OS sends to the browser and sent on through VNC to the X server and then to us, and I don't think we have any way of setting up the X server based on what the OS settings are.
On Feb 18, 2022, at 9:19 PM, Larry Masinter @.***> wrote:
I'm hoping we can make progress on getting Medley Online to work with international keyboards because WE control the configuration of the X-server and VNC and MAIKO and Lisp code.
— Reply to this email directly, view it on GitHub https://github.com/Interlisp/medley/issues/334#issuecomment-1045793756, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB6DAWP34CEQO3I6UNUAINDU34R5LANCNFSM446BRV3Q. Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub. You are receiving this because you were assigned.
Hi, I have a keyboard with Finnish layout and experience also similar problems. For example I'm unable to type the backquote "`" which is often used to write Lisp macros.
I've tried using Medley Online with Lubuntu and Firefox. And running it in a docker container on a server and connecting to it using ssvnc and xtightvncviewer.
I've got an issue open for XQuartz 246 for the fact that XGetKeyboardMapping does NOT return the correct keyboard mapping when the XQuartz option "follow system keyboard layout" is set and the keyboard layout is not the physical one of the mac it's running on (e.g., German system keyboard layout on a US MacBook Pro).
This was discussed on LispCore mailing list https://groups.google.com/g/lispcore/c/BTaSEkzaqN4/m/HwHlSdr-AQAJ https://groups.google.com/g/lispcore/c/BTaSEkzaqN4/m/PQ5tx7THAQAJ
same here with the French layout ("azerty").
I don't know much about Lisp or interlisp. I've tried to launch medley and discovered while most of the keys are correct (a=a, q=q), the upper keys are like on the qwerty keyboard: if I type &é"'( i'll get 12345. To get the () (lowkey 5 and lowkey _ (the key on the right to 9), on azerty, I have to type like on qwerty: shift+9 and shift+0.
@farvardin is your problem on a Mac? This isn't a lisp or interlisp problem at its heart -- the problem is with X key maps sand (on the Mac) XQuartz.
@masinter oups sorry, forgot to describe the OS, it's linux mint 21 and i'm using the official deb package
@farvardin - this all comes about because (for historical reasons with the D-machines and raw access to the Sun keyboards) the Maiko X11 keyboard handling uses the X key code (rather than the key symbol), so it does not get the national keyboard layout applied -- that is left up to LISP code mapping from the physical key to the key symbol.
We don't have good international keyboard support in the LISP code, and we don't have a principled way of passing what X and any configured OS information may have about which national keyboard layout is in play up to the Maiko C code and then to the LISP code.
couldn't we provide a table that users could modify and share? consult it at startup time (people rarely change keyboards mid-session)...
@masinter - one would have thought that the X11 keyboard mapping table would be such a table -- but that is not working with XQuartz. But, we need not only the indication of what national keyboard is in use, but LISP code that sets up the appropriate mappings from the key (bit) number to the Lisp key names. The way to get the desired outcome is NOT by making random incremental changes to the code to try to bypass the existing mechanisms, but to have a complete understanding of what is happening now, what information needs to be passed to Lisp, any changes that must be made (that won't be baffled by people who actually DO use X keyboard maps/XKB) in the C code, and Lisp code to receive that info and set up new keyboard layouts.
@masinter - if someone wanted to write a piece of C code that can reliably interrogate X11 on macOS/FreeBSD/Linux and come up with the keyboard layout information that we need, that would be very helpful (and can be done independently of the existing C code)
On the Lisp side, Virtualkeyboards and other keyboard files in /library provide some interfaces for setting up, visualizing, and installing different keyboard mappings into Lisp’s keyaction tables.
So maybe creating an X keyboard configuration would move part way. I thought the problem, though, was that there are some keys on the German etc. keyboards that are dead with respect to what Lisp sees, don’t result in any bits changing in the keyboard bit table.
On Mar 22, 2023, at 6:25 PM, Nick Briggs @.***> wrote:
@masinter https://github.com/masinter - if someone wanted to write a piece of C code that can reliably interrogate X11 on macOS/FreeBSD/Linux and come up with the keyboard layout information that we need, that would be very helpful (and can be done independently of the existing C code)
— Reply to this email directly, view it on GitHub https://github.com/Interlisp/medley/issues/334#issuecomment-1480454542, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQSTUJKO5WBU7DMDS3WOVVLW5OQ7PANCNFSM446BRV3Q. You are receiving this because you were assigned.
@rmkaplan yes, there are some keys that are dead, though I suspect it's mostly keys that aren't used on the US keyboard (like cursor keys) but we can adjust that if the C code knows the peculiarities of the key codes for the keyboard that is present, and can pass the right information to Lisp such that it can install the correct keyboard file into the keyaction table.
UK English keyboard (under Ubuntu, but I'm guessing all Linux distros) also has minor issues – not ones I can't work around, but it would be nice to have them fixed. And I agree, a properly engineered fix is to be preferred. So the keyboard in use needs to be fetched from the host operating system at Lisp startup time, I think, and used to select the appropriate virtual keyboard.
This is an issue I'd be interested in looking at as a sort of 'get my feet wet' issue, if someone could give me a few pointers.
@simon-brooke I'm not sure this is a "getting feet wet" kind of problem. The problem is the keyboard handling code wasnn't done cleanly -- it seems like every time a new keyboard was to be supported, the keyboard handling code was "patched". And over the years, unfortunately, it was patched in different places.
That said, review keyboard issues #061 #331 #58. https://github.com/Interlisp/medley/issues/531#issuecomment-989305792 "just wanted to get more eyes on this"
Also https://docs.google.com/spreadsheets/d/1FOkrr62TtEhhY49m9U0T_6bvqSGRQt9fBRtMDw0YKtY/edit?usp=sharing is a separate issue. I remember @jcowan made a suggestion to pick another location for the "keydownp" bit vector in order to make it longer, but I haven't found it in the issues....
@simon-brooke - in the Maiko VM code it's pretty messy. But, if you want to figure out how, with common code between Linux, macOS, FreeBSD, and Solaris, with local X11 display and also with running it via SSH with remote display, you can determine what keyboard is in use... I'd be happy to talk about it -- but in detail only once I'm back from a family obligation, after April 15. I have limited time until then.
@nbriggs - OK, it seems to me that what we need to do is identify a token representing the keyboard layout in the host environment, perhaps normalise that, set a global variable in Medley to that token; then have a hash-map which relates that token to an appropriate Medley keyboard layout.
But I note @masinter's comment (above) that the keyboard handling code isn't clean, so I agree this may be a rabbit hole of uncertain depth. Still, if we want a portable Medley, at some stage it does have to be tackled.
I had assumed that there would be a well known open source cross platform library to detect keyboard layouts, but after careful Google search I cannot find one. There doesn't even seem to me to be a standard technique for Linux; although
setxkbmap -print -verbose 10
will tell me I have both British and Icelandic keyboard layouts registered I cannot see that it tells me which one is currently selected. Neither GTK nor KDE appear to have a function to get the current keyboard layout.
Windows has a GetKeyboardLayout library call, which returns an HKL value but there appears to be no documentation on what the values are; however, I suspect they may be the same as the 'keyboard identifier' values given here.
For Mac OS, there's a method for getting the current keyboard layout name but needless to say these names are not the same as those used by either MS Windows or X.org.
So it seems to me that what's needed is a C library with conditional compilation for each supported environment and an enormous lookup table to standardise the values returned to system-independent values. It would be useful not merely to Medley but to many other projects; but it would be a lot of work and an absolute pig to maintain.
Interlisp-10 took input directly from the 'terminal'. Interlisp-D has a 'chatserver' lispusers package or two which take input from a network stream, without any X or keymaps or bitvectors of keydownp.
Some people will want to use a tablet without a keyboard. Rather than maintaining the current system of communicating via key number-indexed keydownp's, couldn't we switch around the translation so that keydownp(keyname) is true if the input stream's last value was keyname's code within 250 milliseconds?
Another problem is the mismatch between Lisp's view of caps-lock and the host oS's view, which can easily get out of sync.
@simon-brooke and so you see why we don’t have this… and setxkbmap does not work on macOS even for a query. I think one has to look at what the code and symbol mappings are in effect to deduce which keyboard layout is in use , but again the mapping query does work on macOS