Yes, and the build failed. This explains some of the issues as the nightly build failed because the packages/libedit/libedit (recursive) submodule was not updated by the build script. That means that the modified libedit that we use was far behind. Note this only applies to the nightly builds; the release builds were ok.
I have fixed the build script and triggered it by hand. You can fetch the binary from Download daily builds for Windows (EU backend) or in a couple of hours from the regular location.
Note that this build also includes two other large rewrites:
xpce (GUI) references are no longer @Integer, but SWI-Prolog blobs. This probably causes some regression. In the end though, this makes the graphics memory handling safe rather than based on some dubious heuristics.
Atom GC now allows type-specific triggering and triggering based on memory usage rather than counts. Should be safe and transparent.
Riight! I thought it was a bit weird I couldn’t see any changes at all when you were saying that bugs had been fixed.
So I’m happy to report that I just got the 02/08/26 daily build for windows from the EU mirror and now I can no longer see the issue I had with garbled command lines in the Epilog console.
Unfortunately I can still see the same kind of garbling in the windows powershell terminal. I’m not uploading any more images but it really looks like the same behaviour.
Anyway this is much, much better, so thank you very much Jan. Er. And Claude too, I guess
I’ll let you know if I encounter any more issues. Let me know if you make any further changes and I’ll try them out again.
Thanks for reporting. I did not check. I’m not yet sure how to handle this. The nice thing about the Epilog terminal is that we have full control over it, so we can simulate typing and read what is actually displayed. This simplifies (fuzzy) testing a lot.
Luckily there was a way to port the tests to deal with the Windows console. Tomorrows daily should have this right. Note that that the Windows console is a little limited when it comes to high Unicode code points and NFD (Unicode combining marks). Should be fine for ASCII though
A lot more has been added and is on its way. One of the addition is to allow for ANSI sequences in the prompt, so you can make bold and/or coloured prompts.
I’ve become pretty comfortable using the MacOS terminal so haven’t been paying much attention to the new GUI. But it seems to have stabilized and, using a recently acquired laptop, gave it a go and noticed a few things:
I can’t point-and-click to reposition the cursor on the input line. (Option-click works on Terminal).
The trackpad two-finger gesture for scrolling the window is backwards, e.g., swiping up scrolls the text down - most confusing.
Doesn’t “feel” very Mac-like: menubar in the window, not the desktop (except for the Windows menu item?), non-native windows, etc. Maybe that’s the price to be paid for a universal GUI, but the previous GUI was pretty good in this respect.
The first two items are pretty fundamental but I haven’t noticed similar comments here, so I wonder if I’m just “using it wrong”. (The previous GUI had neither issue.)
That feature is only in the current GIT source. Rebuild from source or wait for the next release. You don’t need Option, but it seems to work with and without.
I so kindly flipped the scroll direction if the event indicated that scroll requests were “flipped” But, it seems the SDL core does the same … Fixed.
MacOS menus are very hard to deal with in a portable way. The current portability layer (SDL3/Pango/Cairo) does not provide any support last time I checked.
What you get in return is
consistent behaviour between running as GUI application and on the console (same commandline editor)
menus for common Prolog actions. Notably Tools/View threads allows you to inspect what is going on in your long running query at any point you like.
Clickable links from error messages and pretty much anything that can be pinned to a file location. Use Ctrl-Click!
Splitting the console or create additional ones.
Most of this was also in the Qt based version by @CapelliC. Qt is a quite nasty dependency though, making the whole thing hard to maintain. New are clickable links, splitting (rather than tabs) and these are proper xterm compatible consoles that properly deal with processes created using shell/0, shell/1, process_create/3 (latest GIT also makes external processes work on Windows).
There has been a whole round of improvements to the terminal. Notably
Provide full support for xterm-256color escape sequences.
Many more tests and several fixes.
Properly support shell/0 and shell/1 on both Windows and POSIX systems. Before, these just hung on Windows and there were some quirks on POSIX systems. Now you can run vi or emacs or midnight commander Even the mouse works inside!
I’m quite happy not to use Option; that’s just the way MacOS Terminal supports it. Also happy to wait for the release to test.
I agree that moving on from Qt is a wise move and if some rough edges on Mac are the price to pay, that’s fine. Just be aware that it makes it a bit of an outlier GUI on MacOS.
Welcome to SWI-Prolog (threaded, 64 bits, version 10.1.12-68-gc9995defb)
SWI-Prolog comes with ABSOLUTELY NO WARRANTY. This is free software.
Please run ?- license. for legal details.
For online help and background, visit https://www.swi-prolog.org
For built-in help, use ?- help(Topic). or ?- apropos(Word).
61 ?- shell('C:/cygwin64/bin/mc').
false.
That’s in the epilog console, windows 11 64 bits with the 06/08/26 daily build for windows.
How can I can debug this?
Edit: also tried vim (for windows) and Epilog seems to just hang.
Hmm. Do Cygwin executables run in a plain Windows environment? The msys2 version surely works. Does ?- shell. work? I’m not sure how to debug except for building an instrumented version.
Works fine. Both with the version from msys2 and the official VIM installer (picture of the latter in action).
Just to be sure, you are not using an older version of Windows 10, no? These features depend on ConPTY, Windows (broken) pseudo terminals. These where added somewhere during the WIndows 10 lifecycle.
As there is no sensible way to make this work without ConPTYs, I did not try.
Right, OK, I just tried the August,7,2026 daily build for windows (version 10.1.12-95-gf2a6096ed) and that one works alright. The colours are a bit different compared to my powershell console but I guess that’s expected given that they’re, well, different consoles.
AFAIK, the colours are the default 16 entry VGA colour palette. You can redefine the palette using the terminal_image.ansi_colours resource. It also supports 256 and direct color mapping.
Yeah I can report that I’ve already made real use of it. I just needed to downcase some variables quickly (for a special notation that’s fed to a parser) so I opened vim in the SWI console, pasted my code, did a gu$ and copy/pasted the code back to PCEmacs.
Now that I say this, I realise I can do the same thing just fine in PCEmacs, but I know vim much better.
I noticed the comments about console in Epilog so I thought I’d have a look at the shell launched from emacs / File / Shell. The shell window appears but it doesn’t take keyboard input until I resize the window. Once it took input I did a grep to test it but the output is odd
I guess that can be removed. The xpce Epilog terminal is much better. You get it using swipl-win or by running ?- epilog.. That runs Prolog, but in the latest release you can run ?- shell. to get an OS shell. You can also run
?- epilog([goal(shell)]).
The current GIT version extends this a little, adding incremental search and profiles that allows creating Epilog windows with given size, colour and goal to run.
The main advantage of running a shell in PceEmacs was to quickly jump to file:line locations. Epilog does that as well based on embedded terminal escape sequences (that upset the PceEmacs shell mode).
We could revive the PceEmacs shell mode, but I see little added value. It would mean deal with (some) terminal escape sequences and UTF-8 encoding. Delete?
