scryer-prolog is not runnable by MSYS2 emacs on Windows

[jasagredo]

Not sure if there will exist a solution for this, but I thought I might just report it as an issue.

My setup consists of an MSYS2 installation on Windows 11. I use the CLANG64 environment usually. Currently in order to interact with scryer-prolog I have to use a terminal, and I wanted to use ediprolog to ease coding, however ediprolog complains about no prompt being emitted from scryer-prolog.exe.

---

So I tried running scryer-prolog directly from the emacs shell. It turns out that scryer-prolog is not runnable from the emacs shell!

There is no output, nor the process exits, just silence. I tried getting the msvc compiled executable I created the other day in a VM with the same result:

Seems to be a problem with the repl, as the --version flag actually outputs something in both cases:

It even runs full programs (I use :- initialization(run).):

---

If I run scryer-prolog.exe from a terminal in GDB it shows the prompt:

And if I run it in GDB from the emacs shell, it terminates instantly:

^ This is particularly surprising, I would have expected the GDB'ed execution to also deadlock forever, as the call from the shell.

---

My first immediate thought was that perhaps the TERM=dumb of the emacs shell was making scryer faulty, however it seems scryer is still able to run properly in a terminal with TERM=dumb:

---

Also WSL is able to invoke .exe Windows executables, but a WSL emacs also is unable to run scryer-prolog in eshell.

[jasagredo]

Some more information. If I trace the instruction in the dispatch_loop, I end up in this situation (left terminal, right emacs) (notice the number of output lines on the emacs buffer, that took a while 😄):

Going to investigate then the pub(crate) fn read_query_term(&mut self) -> CallResult.

[jasagredo]

Ok, I pin-pointed where the execution stops. It is exactly at:

// src/read.rs
    fn call_readline(&mut self) -> std::io::Result<usize> {
        match self.rl.readline(get_prompt()) {  // <---------------

So it seems to be a problem in rustyline.

[jasagredo]

Ok, I played a bit with rustyline, and voila:

I got ediprolog working for me. I am going to file an issue there hopefully it gets fixed.

The underlying reason is:

• Emacs identifies itself as TERM=dumb which is considered unsupported ONLY ON NON-WINDOWS, it redirects the readline but still flushes the requested prompt. That's why it works on Linux. link to code

• On Windows, the emacs eshell ends up in the last case as is_unsupported always returns false on Windows. That last case does not flush the prompt.

I will propose either flushing the prompt also on that case or actually checking the TERM variable on Windows too.

[hurufu]

Thanks @jasagredo it is really good that Scryer has contributors that actively use Windows. Finally all those issues can be identified and fixed.

[jasagredo]

Should be fixed once Scryer updates its dependency on rustyline to some point after kkawakam/rustyline#834.

[triska]

Thank you a lot for your great help with this!

Please consider reopening this issue until it is corrected, so we remember to take care of it.