Thanks for putting my mind at ease 
I suspect this is mainly the case with Claude, Codex, and maybe a couple of other systems that are specifically fine-tuned (and possibly RLHFād) to assist coding that have improved inā¦ coding. But Iām not sure. Anyway yeah, it seems theyāre everywhere now and Iāve had to change my mind about them, too, not least because Iāve noticed good programmers I know using them in a matter-of-fact way.
This is happening again now constantly, to the point that I canāt use the editor 
Characters are jumping around or disappearing, underscore lines appear suddenly and then disappear, variables and errors etc are coloured in an inconsistent way and so on. I thought this might be my dork theme, but I changed back to the default-ish light theme and itās happening with that one too.
@jan Iām emailing you a zip file with an example file and its md5 checksum.
Hi Stassa
My experience matches your one, I have a (probably dumb) suggestion: save often and then hit
File \ Revert
Interesting. So, the editor starts ok, but after some editing it starts to misbehave and revert brings it back to normal? That might hold a clue. What if you save just before reverting? I.e., is the saved version broken then?
So far I have no clue. The code is OS agnostic, unless you use non-ASCII characters in the file. On Windows, characters > 0xffff are problematic. On all systems handling Unicode continuation codes is problematic, as well as handling double-width characters in fixed width fonts.
It is worth to get an idea on reproducing this. The coming two weeks I do not have access to a Windows. machine, so a fix will have to wait a little (unless someone is willing to try and do some debugging).
Yes. I think the incremental semantic highlighting could be misinterpreting the Windows line terminator. Indeed ghost chars or ābuffer garbageā happens at EOL.
My hint to @stassa.p was indeed to revert immediatly after save, otherwise we lose the last edits, no ?
Thanks, Carlo, Iāll try that today. Until now I would save, kill the buffer, and reopen the file. That also stabilises things for a bit but itās more of a hassle than reverting.
Iām happy to debug but how do I go about it? I have no knowledge of the editor internals. Where do I start?
This was @jamesnvcās guess also:
But @jan thought itās not that:
Oh, I should point out: I donāt have any non-ASCII characters in my current files, but I do have the encoding set to UTF-8 as follows, in my user init file:
:- set_prolog_flag(encoding, utf8).
I turned this on a couple of days ago and I think I noticed the problem before that, but Iāll try turning the flag off today and see if something changes.
EDIT: oops, no, I have plenty of non-ASCII characters in my current project, box drawings and whatnot. I guess Iāll have to keep the flag to utf8.
Btw @jan , I donāt know if the file I sent you will help see the issue. I might have to send you a larger file, but then Iāll have to send you its dependencies also if you need to load it without error. Larger files, with more text, seem to break faster, more often, and more.
As I said, I do not have access to a Windows machine now. Will have somewhere next week. Better reproduction means more likely fix 
So far, all my attempts to reproduce failed. But, then, I never use Windows for development, so I do only very limited editing in Windows.
No rush. I just wonder if me and @CapelliC are the only Windows uses with problems.
Btw, Iāve now noticed distortions and disappearing characters at the listener also. Thatās going to be harder to document and debug, I fear.
Had kind of forgotten. I found the cause: when getting a multiline copy buffer from Windows the lines are separated by \r\n. This is simply inserted into PceEmacs text buffer, while normally \r is not supposed to reach the editor.
Got a fix that will be merged in the next change set soon.
Thanks! Sorry that I couldnāt give you a very good example file.
Recognition also to @jamesnvc who guessed windows newlines might be involved in an earlier comment.
Btw, is the console also affected by this? Iāve had some problems with long queries disappearing when I tried to edit them. Also copy/pasting at the top-level seems to somehow be slowed down, so that when I paste a long line I see it appearing almost character-by-character with visible delay between clumps of characters.
Not entirely sure. Note that the console acts as a terminal with the libedit commandline editor taking care of editing the commandline. Paste currently just sends the characters one-by-one to the input (in Windows over a named pipe, on Unix over a pseudo TTY). That is not ideal. The pasted content should be guarded by escape sequences to indicate it concerns a paste and the content should be handled as a single unit. But then, I do not know whether libedit actually understands that and acts accordingly. If that works it should also handle the character-by-character issue (which only happens on Windows). Worth trying. Otherwise, there could still be some mismatch is the terminal communication and libedit making libedit mistreat the terminal (on Windows).
The only known problem concerns handling Unicode combining characters (e.g., separate diacritics and main character) and Unicode double-width characters (notably used for emoji and various Asian characters).
As the topic is the SWI-Prolog environment, just a question. In my experience, running Windows 11 in a VirtualBox VM under Fedora, the SWI-Prolog GUI tools are a bit sluggish, where the system is nice and snappy on Fedora on bare metal (using Wayland) as well as on my M1 running MacOS. Is this just because I use a VM? Surely, the SDL3+Cairo+Pango solution is more lightweight than the X11 solution on Linux and MacOS, while it is more heavyweight than the old Win32 GDI API on Windows. Experiences?
Iāve pushed a lot of changes. Highlights:
Perhaps a stupid question and not relevant , just curious, which claude plan are you using?
So far āProā. Iām pretty impressed in its ability to diagnose issues and come with solutions. Sure it is not all perfect, but I think it is about time to reconsider my working habits seriously. It is as exciting as it is scary ā¦
Nothing feels changed in terms of responsiveness and speed on my native Windows install (ānativeā as in itās not a VM). That is, except for the pasting issue I point out above. I think you say you have noticed it yourself? Otherwise SWI feels the same as always with and without the IDE.
Thanks. Iāll try the new version ASAP. I guess thatās all going in the daily build for Windows?
I have to say this but my experience is that ever since the switch to Epilogue using SWI has felt like a pain, which is quite unlike the way it was before.
Some of it is things that changed unexpectedly. Just to take one example, the way the textual debugger works has changed (I only ever use the text debugger ). Previously, I could immediately spy a goal at the top-level by entering spy(predicate/arity). Now I have to enter [debug] first. It took me several agonising minutes to figure that out when I installed the new version that made this change and it was very confusing, but I guess thatās down to me not reading the release notes carefully. On the other hand, I never did and I never had such scary surprises either.
Other issues have been actual bugs, like the newlines thingy, but of course weāve had those forever and itās not the end of the world obviously.
But I do get the feeling that all the stressfull times Iāve had with SWI recently coincide with your increasing use of AI for code generation. Iām happy to confess Iām a bit prejudiced or a bit skeptical, however you prefer to see it.
However. Anything that can make you code faster is both good and dangerous at the same time. Consider cars. We can go hundreds of times faster in cars than we can run on our own, but that just means that when something goes wrong we get hurt hundreds of times more also. Same thing with code. The ability to generate a lot of code faster does not necessarily entail the ability to catch bugs faster.
Finally, if AI code generators are not significantly better coders than humans -and I donāt think anyone believes they currently are- weāll still see that they generate new bugs even as they fix old ones, but that just means weāll see many more bugs much faster than we can catch them and fix them.
Anyway, this is the new world weāre all in and I have to also say that I have changed my opinion on AI code generators partly because of the way you, @jan, have embraced them, partly also because other progammers I trust and respect do. Brave new world.
Good. That is a relief!
Yes, the current latest daily build should have all that.
That is of course not good I think it has little relation to me using AI these days as a coding agent. It seems to be more related to the radical switch in architecture of the entire environment and releasing too early. Replacing 40 years old code with something completely new and changing the architecture for notably swipl-win is hard. Notably as automatic testing the GUI is not easy Probably we need to support automatic testing of these parts
That surely was my error when introducing thread classes to improve debugging of multi-threaded applications that create threads on the fly (notably the HTTP server).
In general, recent coding has cleaned the code base a lot and made it pretty much fully (C) standard compliant. Any change comes at a risk though so yes, this has introduced bugs Today, most C functions that used to return int have been changed to either return the new C bool or values from some enum type. That has fixed several bugs (probably ones that kept mostly hidden as they were in rarely used code paths) and made it much easier to understand the control flow. Unfortunately it also introduced bugs in more frequently used code paths
Iām changing my opinion on these nearly daily The code generators quickly get better and I discover better ways to use them. Iām feeling like a beginner again, which is quite fun
I understand all of that and hope I donāt come across as too whiney. I understand that many of the changes are for the better, to improve code quality and consistency etc, for example the way print/write now works at the top-level. And sure as day itās a fact of life that fixing bugs almost always ends up introducing new ones
Iām always grateful to you for your work on SWI and Iām happy if youāre having fun 
After the latest upgrade (version 10.1.6 running on Windows 11), copy the text selection in a source window seems not working anymore, but works as usual (i.e. it requires \C+c).in a terminal window.
From menu Help \ show key bindings I filter (apropos) copy and I see that
\C-\S-c copy āCopy selectionā
but I canāt tell what \S could mean, given that Ctrl+Shift+c doesnāt work.
I synced the key notation with Emacs. This means Control+Shift+C. I know there was a problem with copy on the Mac. That has been fixed in the source. Do you mean Edit/Copy does not work as well in the editor? You might try the daily snapshot as the MacOS patch may also apply to other platforms. Please report!
Thank you very much, itās working now.
I wonder which situation would profit of the sequence \C-\S-c, since the clipboard gets filled immediately on selection change.
Maybe there is some option to alter the behaviour ?
Iām asking because I would prefer the mainstream behaviour of explicit ācapturingā the selection, given that on Windows I use a GUI that allows to select among past yanked chunks.
EDIT:
Sorry for the naive question, I found
editor.auto_copy: @off
in [ Settings \ GUI preferences ]