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.