Maybe that should be the default these days? I like the X11 primary selection with middle-button paste a lot. X11 is nearly dead though and most modern platforms only have a clipboard 
I think could be useful for newcomers.
Nah, X11 will live through Xlibre, unencumbered by politics. E.g. vsync patch is now not in limbo.
This has also been changing unpredictably for me every time I install the latest daily builds for widows. Some times there is no copy-selection shortcut in the menu and auto-copy is off by default (so if I copy a bit of text it doesn’t go to the clipboard) and the windows shortcuts (Ctrl + C/V) don’t work. Other times there is a shortcut in the menu and auto-copy is on. I haven’t kept track of which versions do what but the behaviour seems to change from version to version.
The same goes for some other things in the daily builds e.g. whether I need to enter [debug] before I can trace a spied goal at the top-level, or not. Another thing that seems to change is the contents of the help menu during tracing (when you press “h” to show options).
However I haven’t been able to code much in the last month (long story) so I can’t give very clear information on this. But what’s clear is that there is some regression between daily builds and also between daily builds and development versions. I currently have four versions of SWI on my windows machine to try and figure out which version has which features.
For the same reason I haven’t been able to test the fixes for the problems with copy/pasting I reported at least not thoroughly, but for the limited time I spent in the editor that seems to work OK now.
Sorry about that. Although, some looks suspicious. Surely enabling debug mode on spy/1 was broken at some point, but fixed after and AFAIK never broke again. There was a bit of back and forth wrt. copy, probably as a result of SDL3 versions as well as Prolog versions and possibly because the build environment for daily and releases was not the same (synced).
A new release is around the corner. That hopefully stabilizes things. The changes are large. Forthcoming:
- More Unicode support. Notably
- Fully support the complete Unicode range in xpce, including on Windows.
- Support Unicode double-width characters and Unicode combining characters in Epilog terminal, the editor and through our copy of libedit for the Windows console as well as any modern terminal.
- For Prolog itself
- Update to Unicode 17.0
- Sync identifier, variable and white-space identification with the Unicode recommendations and ongoing PIP discussion (may not be final).
- Make line_position/2, etc. aware of Unicode combining marks and double-width characters.
- Make format/2,3 tabs aware of these.
- Support Identifier Unicode normalization a new Prolog flag
unicode_atoms.
- By default disable auto-copy on Windows and MacOS. Also make the Epilog terminal sensitive to the
*.auto_copypreference. - Support ^Z as alternative end-of-file on Windows.
Anything else on the wish list?
I had the pleasure to learn a lot while porting xpce from X11 to SDL3. I have used X11 since it was pretty new and thought the network transparent design was quite neat. Over the years it collected quite a bit of overhead nobody wants these days while it some modern features were hard to fit into the X11 design. This turned it into an ever growing mess. Worse though, the security of X11 is a nightmare. Any program that gains access to an X11 display can inspect everything in other applications, including faking events. Wayland has been designed to minimize the ability for applications to leak information. In some senses to the level where it hurts usability, such as the lack to open a window at some location on the display. Using X11, it is quite simple to find an application window, create a transparent window that you place on top of it and proxy all user events without anyone noticing No more on Wayland.
So, I now agree is it time to move forward. Surely it is a nuisance, but you get security and performance in return.
Take the daily build. That should provide pretty much stable behaviour running swipl and swipl-win and deal with double width and combining characters (zero width as they merge into the preceding character).
The goal is slowly getting pretty clear. At the moment I’m working on refactoring the support and make it all nice and consistent.
Thank you for your hard work Jan and I’m sorry I haven’t been able to make a detailed report, although it seems like you are aware of the regressions already.
And now that you mention it, unicode rendering and discrepancies between native terminal and IDE, like @anon37422618 shows above, were another thing I noticed.
I really haven’t been able to work with SWI recently, again sorry for being so vague about the issues I noticed.
The Epilog console is still broken for me. I’m on the 27/07/2026 daily build (64 bits, 10.1.12-19-gafad12355-DIRTY) on Win 11. I hope it’s OK to upload a small screenshot (~50kb):
This happens when I try to edit my last command with Up arrow. In particular, when I try to delete a character and write a new one, I see the new character on the line above the line I’m editing, for example see the lonely “1” above the block of lines at the bottom. Then if I keep pressing Up arrow, new lines start appearing above the line I was editing until the entire monitor fills up, from bottom to top.
In the screenshot above you can also see where some new output (the table with the crosses and dots) is drawn on top of the text above it).
I thought this might be a regression but I tested with my last daily build version (64 bits 10.1.6-3-ge77bb2ad3-DIRTY) and it’s happening there also. That’s strange because I had thought this was fixed at some earlier point.
Btw, I’m not sure when it’s OK to start posting bugs again so I hope this is alright to report now.
I was very sorry to see that xsnow and xroach were not working anymore under Wayland. At least I found „webroach“.
Sure it is. Please try tomorrows daily build. Its an AI generated patch. I doubt I could have found it in a reasonable time …
Thank you Jan. Unfortunately I don’t think it worked. Here’s the latest daily build I installed just now:
I mean… sure you could have. I’ve used SWI for, what, 15 years now? All this time I’ve watched in awe as you fixed 80% of bugs I reported the day I reported them, or next day. By hand, no Claude. I think even you underestimate the value of having worked on a project for almost 40 years and knowing it like the back of your hand. No way AI is ready to match that yet, no matter how much context you give it. Maybe a few (or many) years from now it will, but not yet.
But like I said before, if it’s making your life easier then I’m not going to bitch about it. Use whatever you like. And I’m not in any hurry, just to be clear. Please take your time, I don’t think this is a very common bug or more users would be reporting it (I guess most people using SWI are sensible and use Linux rather than Windows).
Sure, but this one is rather hard. With version 10, I decided to unite the I/O and GUI application handling between the platforms by porting the swipl-win.exe console to xpce and use the same commandline editor (libedit) on all platforms. So, I ported libedit to Windows (by hand). Just, it did not really proof to be ready for this, notably not on Windows as it had no support for Unicode code points > 0xffff, so support for Unicode NFD characters (on any platform) and generally proofed too immature. I’ve used Claude to create a random test procedure and find issues that way. After finding an issue it had to simplify the case, turn it into a unit test, fix it and try again. Without Claude I would probably have given up on unifying the architecture for all platforms. Surely it will take a little while, but I do have good hope this will eventually work.
Note that we have to deal with the native terminal emulators, the Windows console and the xpce terminal emulator. The main issue seems to be wrapped lines. That was problematic from the start
P.s. I assume this is using swipl-win.exe? It would probably also help to have a little more context on exactly what you do. Last time Claude managed to find a bug that could have been related to your finding, but possibly it just found another bug …
Have you tried using a statement like this at times in a prompt, especially helpful after do refactoring on code or bug fixes as the needed context typically has most of the details.
Are there any gaps you see? Are there any pain points I should consider?
Thanks. There is a nice story about debugging the terminal. I asked Claude write additional methods that allow it to read the content of the terminal and position of the caret. Then I asked it to write a Prolog program to compute the correct result of edit operations on the commandline. Next, I asked it to write a fuzzy tester to drive the terminal, compute the Prolog result and compare these. I was not precise enough what I wanted it to do … It ran the fuzzy tester and generated unit tests from these … but it did not create unit tests for failing fuzzy tests. Instead it claimed this made no sense as the tests were failing 
I had to be more precise, explaining the idea of fuzzy testing, extract failing tests to unit tests, fix them and repeat.
P.s. Need to verify, but the real problem seems to be communicating the correct size of the Epilog terminal to libedit. This uses signalling with SIGWINCH on non-Windows but no proper work-around for Windows
That’s just… heroic-level software engineering. Claude or no Claude. Thanks for that <3
Of course! No doubt about that. For the time being let me stress again that it’s not a huge blocker, I can edit my command line in my editor, or even open the history file directly if I could be bothered. It’s just my bad repl style enabled by SWI-Prolog’s listener being so nice, that I keep writing longer and longer commands and then I go back and edit them. Sometimes I will remove parts of a long query with streaming comments and then add them back in etc.
Aye. This happens when I try to edit long command lines. I mean ones that wrap over more than one line in the terminal.
So the two screenshots above are from swipl-win.exe, yes. But I do get the same issue with swipl.exe, which btw I run in powershell (not cmd.exe; I’m not sure anymore if that’s the same console or not but I think it is).
What I was doing in the last screenshot is that I pressed Up-arrow to return to the last command, then I used Home to return to the start of the query, then pressed Right-arrow to position the cursor right after the “_L = 20” visible at the top of the screenshot (although I don’t think that’s the original line; it appeared later). Then I pressed Backspace to delete the “20” because I wanted to enter a different number there.
As soon as I pressed Backspace the “0” in the “20” disappeared (correctly) but at the same time the cursor climbed one line above my query. When I pressed Backspace again the cursor climbed one more line higher without deleting the “2” this time.
[EDIT: after all that I pressed Up-arrow a few more times and even entered “version.” for good measure, that’s why you see the welcome text printed in the console over and mixed-in with my query. I think the error message happened when I pressed enter after typing “version”. I think that suggests there’s some text that gets stuck in a buffer. Maybe?]
Oh and btw when I went through the same motions again right now to check my self, I got this message:
Canno destroy display @display/display: has frames
This is the first time I see this though. The behaviour in windows powershell is the same.
Sorry, I’m not sure where to look for more context. What should I be looking at? Can I log something? Maybe I should send you some video of my swipl-win.exe and swipl.exe interactions? Will that help?
btw, is it OK to post images here? I understand there’s a concern with bandwidth?
Oh btw, note that I usually tile the terminal and the (SWI) editor side-by-side. I don’t know if that somehow affects the ability to measure the size of the terminal screen? But I just tried it again with a maximized window and I still have the same problem.
And I also tried with the terminal window in its “default” (I guess there’s a default?) size, I mean the way it is when it just pops up, without me trying to tile it or maximize/resize it and I still get the same garbling of text. Same query every time like the long one in my last screenshot above. I don’t know if that helps.
This is, AFAIK, related to multiple displays. Notably adding/removing displays. That is still problematic
I has a default size (80x25). That too goes through a resize sequence though.
Your messages are fine. I find it rather hard to figure out what happened and the screen shot has the disadvantage that I cannot copy/paste. Claude seems to be able to reproduce them and distil test cases from them though It may come up with the wrong way to reproduce the broken display, so fixing another bug … It has now added quite a couple of resize unit tests as well as fixes … We’ll see how much it fixes … I’ll let you know when I pushed the changes to trigger the next daily build.
Oh right. I have my laptop on the table with the screen open and an external monitor connected for good measure. I don’t remember seeing this message before though.
Thanks!
Please give tomorrow’s build a try. This fixes quite a few issues with resizing the Epilog window while holding a long input line. A little added benefit is that left-click inside the command being edited in Epilog moves the caret to this position.
Please keep reporting success/failure!
Thanks Jan. I guess I’m waiting for the 02/08/26 build? I downloaded the 01/08/26 build just to be sure and tried it but I get similar behaviour but tbh it does look a bit different now, though still glitching. I’m embedding a gif, please yell at me if I’m posting too many images. It’s low quality to keep it small but you can see what’s going on if you make it a litle bigger:
To be clear what I’m doing in that screen recording is I’m pressing Up-Arrow, then Right-Arrow (just to show what happens after I noticed it) then Backspace. When the cursor jumps to the top of the terminal, that’s the Backspace. It really looks like there’s some buffer not being emptied.
Btw, I think there may be a problem with version numbers. The version number for the 01/08/26 daily build for windows that I downloaded today is 10.1.12-40-ge0fb3356c-DIRTY but this is the same as for the 31/07/26 daily build for windows that I downloaded two days ago (you can see it in the last screenshot I posted 2d ago). Is that right? I think you said before version numbers aren’t updated consistently? Otherwise is it possible there’s a glitch in the windows build system and I basically missed your actual bug fixes?
I note the 01/08/26 build doesn’t let me position the cursor with the mouse button. Which version am I on?
EDIT: btw, same behaviour on the windows console with swipl.exe. Above is swipl-win.exe.