# XPCE keyboard input issues **URL:** \ **Category:** General\ **Tags:** bug\ **Created:** [August 27, 2025, 7:09am UTC](https://swi-prolog.discourse.group/t/xpce-keyboard-input-issues/9246 "2025-08-27T07:09:06Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![CapelliC](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/capellic/32/17_2.png) [@CapelliC](https://swi-prolog.discourse.group/u/CapelliC)\ **Post date:** [August 27, 2025, 7:09am UTC](https://swi-prolog.discourse.group/t/xpce-keyboard-input-issues/9246/1 "2025-08-27T07:09:06Z")
> [@Ann: SWI-Prolog 9.3.28](https://swi-prolog.discourse.group/t/ann-swi-prolog-9-3-28/9161/9): > > Reporting often helps A keyboard regression: square brackets (i.e [and], ASCII codes 91 and 93 ) aren’t available on italian keyboards, so we need to keep pressed the ‘Alt Gr’ key before hitting è and +. But instead of inserting the expected symbol, the editor moves the caret al start of in-edit clause ( on [) and then at the end of the following clause ( on] ). Using a desktop, the ASCII codes can be inserted by the trick ALT+DECIMAL\_CODE on numpad, but on laptops this isn’t ( always ? ) available… Now I will try to debug and fix this behaviour, but - probably - it will take too much time to help … ---
**Author:** ![jan](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/jan/32/4_2.png) [@jan](https://swi-prolog.discourse.group/u/jan)\ **Post date:** [August 27, 2025, 7:49am UTC](https://swi-prolog.discourse.group/t/xpce-keyboard-input-issues/9246/2 "2025-08-27T07:49:22Z")
> [@CapelliC](#): > > A keyboard regression: square brackets (i.e [and], ASCII codes 91 and 93 ) aren’t available on italian keyboards, so we need to keep pressed the ‘Alt Gr’ key before hitting è and +. I guess we are talking about a PC keyboard. Using Windows? I found a layout picture at [https://learn-attachment.microsoft.com/api/attachments/813c2e99-a21b-4b99-9123-a21ae79e9dca?platform=QnA](https://learn-attachment.microsoft.com/api/attachments/813c2e99-a21b-4b99-9123-a21ae79e9dca?platform=QnA) And, if I understand correctly, Alt-è/+ should give `[]`, no? It seems it is sending Alt-[and Alt-], which are bound to the Emacs commands sentence forward/backward (mapped to clause forward/backward in Prolog mode). The relevant code is in `packages/xpce/src/sdl/sdlevent.c`, CtoEvent(). The problem is whether to consider a key as text input or keydown as modifier(s)+key. SDL first sends a `SDL_EVENT_KEY_DOWN` holding the key+modifier and than briefly after a `SDL_EVENT_TEXT_INPUT` holding the decoded key. When in doubt, we start a timer on the key-down that triggers `MY_EVENT_KEYDOWN_TIMEOUT`. If there was a relevant text input, we do nothing, else we send the key-down from here. Please have a look at the code. You can debug using ``` ?- send(@(emacs), kind, user). ?- debugpce(keyboard). ``` ---
**Author:** ![CapelliC](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/capellic/32/17_2.png) [@CapelliC](https://swi-prolog.discourse.group/u/CapelliC)\ **Post date:** [August 27, 2025, 8:42am UTC](https://swi-prolog.discourse.group/t/xpce-keyboard-input-issues/9246/3 "2025-08-27T08:42:09Z")
The pictured layout doesn’t match my experience. Anyway, since the other two frequently used symbols (@ and #, both requiring the ‘Alt Gr’ switch on my Windows PC keyboard layout) aren’t available, I guess all boils down to intercepting the scan code for the ‘Alt Gr’ modifier. Maybe [this answer](https://stackoverflow.com/a/79355031/874024) will help. ---
**Author:** ![jan](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/jan/32/4_2.png) [@jan](https://swi-prolog.discourse.group/u/jan)\ **Post date:** [August 27, 2025, 9:07am UTC](https://swi-prolog.discourse.group/t/xpce-keyboard-input-issues/9246/4 "2025-08-27T09:07:19Z")
The idea is that Alt-Gr-\* should work out of the box. Note that we are working through the SDL3 abstraction layer, so it matters what happens at that level. If all works as intended, these sequences should be handed like this: - The down for Alt-GR-\* triggers a 10ms timer and otherwise does nothing. - The text input event decides this is text input. - The timer event is ignored. Using `?- debugpce(keyboard).` should verify that. Possibly the debug output from `swipl-win` is lost though. To avoid that, start `swipl` in a console and start `?- emacs.` from there. Do not forget `?- send(@(emacs), kind, user).` as PceEmacs is initially a system service for which debug events are ignored. P.s. Note that now also on Windows, the GUI tools may be used both from `swipl-win.exe` and `swipl.exe`. This used to work only on non-Windows systems. ---
**Author:** ![jan](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/jan/32/4_2.png) [@jan](https://swi-prolog.discourse.group/u/jan)\ **Post date:** [August 27, 2025, 12:16pm UTC](https://swi-prolog.discourse.group/t/xpce-keyboard-input-issues/9246/6 "2025-08-27T12:16:40Z")
I know there are a zillion keyboard layouts. What matters is that Alt-Gr-\* should work as normal. The question is on which keyboards using which OSes this works and if it doesn’t, whether that is an SDL3 issue or something wrong with the logic I use to translate the SDL3 events into xpce keyboard events. So, if it does not work for someone, please use the described debugging technique and report what happens. Please specify the Prolog version, OS and keyboard as well as the key combination that is supposed to work. Reports on non-US keyboards that do work correctly may also be useful … ---
**Author:** ![jan](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/jan/32/4_2.png) [@jan](https://swi-prolog.discourse.group/u/jan)\ **Post date:** [September 3, 2025, 1:03pm UTC](https://swi-prolog.discourse.group/t/xpce-keyboard-input-issues/9246/8 "2025-09-03T13:03:25Z")
I have pushed a number of fixes that - Avoid interpreting text input created using Alt-gr or the Apple option key as Emacs Meta-sequences. This seems to fix using Alt-gr-[ on Italian keyboards. - Interpret any code point above 128 as `insert_self`. This fixes input of non-ASCII characters. As far as I can tell, dynamically switching the keyboard layout on Windows (11) works fine despite reports of the opposite. May be fixed in between 🙂 At least, switching between US and Italian layout works fine for me. Ok, this is using Windows 11 running in a VirtualBox VM under Linux. It is claimed though that the VM simply forwards the raw keyboard events to the guest. The fact changes to the layout on the Windows side do not affect Linux, nor the other way around seems to confirm that. ---
**Author:** ![CapelliC](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/capellic/32/17_2.png) [@CapelliC](https://swi-prolog.discourse.group/u/CapelliC)\ **Post date:** [September 3, 2025, 1:25pm UTC](https://swi-prolog.discourse.group/t/xpce-keyboard-input-issues/9246/9 "2025-09-03T13:25:41Z")
Thanks Jan Alas, I still have some complains (using ver. 9.3.29, should I switch to daily releases to get all fixes ?) … - minor problem: the Del key doesn’t work - showstopper: in a multi tab session the focus event (probably) get lost, then the caret doesn’t change to the red triangle, and no editing is possible. This didn’t happen in the first session I started (the first time after the download and install), but after some working - usual stuff, multiple modules editing and debugging - the whole app freezed after some switch between 2 tabs. I had to use the Windows process manager to kill the processes… right now I downgraded to ver. 9.2.9, to complete my duty, but if necessary i can reinstall - eventually the daily release - and test again ---
**Author:** ![jan](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/jan/32/4_2.png) [@jan](https://swi-prolog.discourse.group/u/jan)\ **Post date:** [September 3, 2025, 1:47pm UTC](https://swi-prolog.discourse.group/t/xpce-keyboard-input-issues/9246/10 "2025-09-03T13:47:16Z")
> [@CapelliC](#): > > should I switch to daily releases to get all fixes ?) To get the fixes I described above, yes. These are not in 9.3.29. They should be in tomorrow’s daily build. > [@CapelliC](#): > > the Del key doesn’t work You mean forward delete in the console window? At least, that is the one I can reproduce. As Emacs user I always use `Ctrl-D` 🙂 > [@CapelliC](#): > > in a multi tab session the focus event (probably) get lost You mean split-window console using Shift-Ctrl-O or the _Split horizontally_ menu? Sessions should not affect each other. Some fiddling do not show any issues. We need to find the particular sequence of events, which is not easy ☹ ---
**Author:** ![CapelliC](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/capellic/32/17_2.png) [@CapelliC](https://swi-prolog.discourse.group/u/CapelliC)\ **Post date:** [September 3, 2025, 2:23pm UTC](https://swi-prolog.discourse.group/t/xpce-keyboard-input-issues/9246/11 "2025-09-03T14:23:42Z")
> [@jan](#): > > We need to find the particular sequence of events, which is not easy indeed… tomorrow I will test the daily build. About the multi tab, I was simply opening the module file using ‘Open in tab’ from the context menu (i.e. right click on module name on :- use\_module(sudoku\_carlo).) ---
**Author:** ![jan](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/jan/32/4_2.png) [@jan](https://swi-prolog.discourse.group/u/jan)\ **Post date:** [September 3, 2025, 3:04pm UTC](https://swi-prolog.discourse.group/t/xpce-keyboard-input-issues/9246/12 "2025-09-03T15:04:02Z")
> [@CapelliC](#): > > About the multi tab, I was simply opening the module file using ‘Open in tab’ from the context menu (i.e. right click on module name on :- use\_module(sudoku\_carlo).) I see. This works fine on Linux. Creating a new PceEmacs tab using the popup, following some linked predicate or file indeed causes the editor to loose focus on Windows. I can regain it by clicking outside the editor and then again inside the editor. I’ll have a look. P.s. pushed patches to make the DEL key work in the console. Should be in tomorrows daily.