Windows: no choice on printing more answers

[jasagredo]

I built scryer-prolog from very close to master in --release mode, both with Clang and GCC toolchains and in both cases the repl does not wait for user input on listing more answers. As I press Enter on the query, the , ... . is printed instantly:

➜ scryer-prolog
?- char_type('a', X).
   X = alnum
;  ... .
?- halt.

➜ scryer-prolog -v
v0.9.4-210-gff034326

My environment is Windows 11, using MSYS2 CLANG64/MINGW64.

[bakaq]

I can reproduce with x86_64-pc-windows-gnu through Wine (even in debug mode).

?- use_module(library(charsio)).
   true.
?- char_type('a', X).
   X = alnum
;  ... .
?- (X = 1; X = 2).
   X = 1
;  ... .

This doesn't happen in x86_64-unknown-linux-gnu.

[bakaq]

Ok, I checked and this still happens even before #2527, which would be the obvious culprit here.

[jasagredo]

I printed some stuff:

?- char_type('a', X).
Read input: [99, 104, 97, 114, 95, 116, 121, 112, 101, 40, 39, 97, 39, 44, 32, 88, 41, 46]
   X = alnum[10]
 ; ... .
?-

Where the [10] (decimal for \n) corresponds to an Enter being detected automatically in get_single_char(C) in read_input in toplevel.pl.

The Read input: sequence corresponds to what is returned by rustyline printed as:

        match self.rl.readline(get_prompt()) {
            Ok(text) => {
                println!("Read input: {:?}", text.as_bytes());
                ...

I don't know much of the interactions here, but it seems to me like rustyline is pushing a \n to the input? that or the last \n is not consumed?

[bakaq]

Maybe this is a \r\n vs \n issue? As in, rustyline sends the query on \r and then get_single_char/1 consumes the \n.

[jasagredo]

No, I found the issue. Windows sends KeyEventKind::Release events, and linux doesn't. In a toy example based on rustyline example:

use rustyline::error::ReadlineError;
use rustyline::{DefaultEditor, Result};
use crossterm::terminal::*;
use crossterm::event::*;

fn main() -> Result<()> {
  ...
  loop {
        let readline = rl.readline(">> ");
        enable_raw_mode();
        let key = read();
        disable_raw_mode();
        println!("Key: {:?}", key);
        ...
   }   
...
}

I found that on Windows I get:

>> a
Key: Ok(Key(KeyEvent { code: Enter, modifiers: KeyModifiers(0x0), kind: Release, state: KeyEventState(0x0) }))

and on Linux (even WSL) it blocks because there is no next key event:

>> a

[jasagredo]

Bingo:

➜ ./target/release/scryer-prolog.exe
?- char_type('a', X).
   X = alnum
;  X = alpha
;  X = alphabetic
;  X = alphanumeric
;  X = ascii
;  X = ascii_graphic
;  X = hexadecimal_digit
;  ... .