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 …
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
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 will help.
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.
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 …
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.
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
To get the fixes I described above, yes. These are not in 9.3.29. They should be in tomorrow’s daily build.
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
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
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.
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.