Enabling international keysets?

[Lispl-Wicht]

I am running Berkeley Logo 6.2.5, installed as a prebuilt Debian package on Debian Trixie.

After using it for some time, I noticed that the US keyboard layout seems to be used exclusively, regardless of the system keyboard settings.

In earlier versions, the German keyboard layout was respected (in my case), so I initially assumed that the system keyboard preferences were still being passed through. Only later did it occur to me that the US layout might be hard-coded — and switching my system keyboard to US indeed makes the behaviour consistent.

My question is:

Is this behaviour specific to the Debian package (e.g. a build or configuration choice)?
Can international keyboard support be enabled at compile time?
Or is the US keyboard layout hard-coded in Berkeley Logo itself?

Thank you very much for any clarification.

[daveshenal]

This is a known, open upstream limitation, not something specific to the Debian package or something you can switch on at compile time. See Issue #5: Unicode support, which describes this exact symptom: a user built the wxWidgets version from source on Ubuntu 18.04 and got the same behavior - typed text doesn't show up correctly once you switch to a non US keyboard layout, while it works fine in English/US.

The maintainer's own explanation in that thread is the actual root cause: the interpreter's core code is old and assumes characters are fixed width throughout (it does direct pointer arithmetic on strings, e.g. for BUTFIRST/BUTLAST running in constant time), which is fundamentally incompatible with proper Unicode/UTF-8 handling. So it's not that US is hardcoded as a deliberate choice - it's a side effect of the interpreter not yet handling multi byte or non ASCII input correctly anywhere in its string internals. There's no build flag for this because there's no alternate code path that handles it; it would need real Unicode support work in the core data structures, which the issue also notes would be a non trivial rewrite (the maintainer in that thread leans toward recommending eventual UTF-32-style fixed width characters as the fix).

That also explains what you observed about older versions: pre-6.x packages (5.5-era) likely used a different text input path that wasn't affected the same way, which is consistent with another commenter on that same issue who reports going back to the 5.5-3 package specifically to get their layout working again.

Your best options right now: follow/comment on #5 for updates, or as the practical workaround you've already found, keep your system layout on US while using Logo (or switch only when typing comments/strings that need it, then switch back).

[Lispl-Wicht]

Thank you very much for the detailed explanation and for pointing me to the relevant issue — that clarifies the situation perfectly.

My question was motivated by the fact that I’m currently implementing a Logo system in Common Lisp and using Berkeley Logo as a behavioural reference. Since Common Lisp has native Unicode support, I was wondering whether my testing environment (the Berkeley Logo REPL) could be adjusted easily by compiling from source.

Knowing now that this is an upstream limitation rooted in the interpreter’s core string model answers that question conclusively.

Thanks again for the clear and helpful explanation.