Scryer-prolog: Scryer Prolog behaves differently in Emacs shell

[triska]

While going through the Conformity testing collection, I noticed that Scryer Prolog behaves differently in Emacs than on a terminal application in unexpected ways.

For example, please consider case #7:

writeq('\
'). % "\\\n" 

In Emacs, when I do M-x shell RET, start Scryer Prolog in that shell, and post the query, I get:

?- writeq('\
'). % "\\\n" 
caught: error(syntax_error(invalid_single_quoted_character),read_term/3)
?- caught: error(syntax_error(invalid_single_quoted_character),read_term/3)
?- 

On the other hand, on a system terminal, I get (exactly as expected, i.e., conforming to the standard!):

?- writeq('\
'). % "\\\n" 
''   true.

Does anybody have an idea what could cause such a discrepancy? I would like to set up the Emacs shell in such a way that it reliably mirrors the behaviour that Scryer exhibits on a terminal, so that I can quickly go through all test cases (using conformity_testing_copyline.el). My hope and goal is that Scryer Prolog will be included in the table once it passes all tests.

[mthom]

I would like an answer to this myself! There's many discrepancies between Eshell and the UNIX shell. Not just when using Scryer, but generally.. with Scryer it's especially pronounced because key capture doesn't work.

[triska]

I have filed an Emacs issue for this:

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=42588

[mthom]

Thank you!

[UWN]

The first error already occurs when one enters writeq('\ alone. So for some reason Scryer probably gets two newlines. Or maybe interprets carriage return and newline as two separate newlines....

[triska]

@notoria: You already excellently corrected a different issue involving the terminal, are you interested in taking a look at what is going on here? I would greatly appreciate your help with this issue, since we can then quickly run all ISO test cases!

[notoria]

When reading the input, Scryer-Prolog has two ways for interaction, terminal-style interaction and file-style interaction due to readline. Emacs must be using the file-style interaction.

There are various ways to reproduce the error:

$ echo "write('\n'). % \"\\\\\\\\\\\\n\"" | scryer-prolog 
caught: error(syntax_error(invalid_single_quoted_character),read_term/3)
caught: error(syntax_error(invalid_single_quoted_character),read_term/3)
$

$ cat test.pl 
writeq('\
'). % "\\\n"
$ scryer-prolog < test.pl
caught: error(syntax_error(invalid_single_quoted_character),read_term/3)
caught: error(syntax_error(invalid_single_quoted_character),read_term/3)
$

[UWN]

@notoria, how does readline decide which mode to take? In particular in your example of input redirection from test.pl, it is the sole responsibility of readline/Scryer. Otherwise, Emacs sets the TERM variable to dumb when using M-x shell. Other options are M-x term or M-x terminal-emulator all with some Emacs-specific value (but it seems that @triska will not like these two other options since all Emacs bindings are gone..)

[notoria]

readline checks if the terminal is a stdin tty (source).

After some testing, by removing this line: https://github.com/mthom/scryer-prolog/blob/249f034a38ed23c48c3334d1d1d996e106d2df47/src/read.rs#L70
The issue seems to be solved.

[triska]

@notoria: Thank you a lot for looking into this!

When I apply this change, many conformity tests now work also within Emacs.

However, there still remain differences between Emacs and the terminal. For instance, when I try #189, I get in Emacs:

?- writeq(-{}).
caught: error(syntax_error(incomplete_reduction),read_term/3:1)

Whereas on the terminal, I get:

?- writeq(-{}).

- {}   true.

On the terminal, I also had to press RET twice after entering the query.

[triska]

Emacs can be detected by checking whether the environment variable INSIDE_EMACS is set.

[UWN]

Emacs can be detected by checking whether the environment variable INSIDE_EMACS is set.

INSIDE_EMACS is set both for M-x shell and M-x term. So it does not help to distinguish these two cases.

[notoria]

This works:

$ echo "writeq(-{})." | scryer-prolog
- {}   true.
$

Emacs must be the culprit now. Is there a way to see what Scryer is receiving from Emacs? (Adding println!("text: {:?}", text); before this line could help).

So the extra \n was to solve RET _twice_.

[triska]

Thank you a lot @notoria!

As far as I can tell, this now works perfectly! Is there anything that remains? (I am asking because you mentioned that the patch partially resolves this issue.)

[notoria]

It was about the Emacs issue, otherwise it's good.

[triska]

Perfect, thank you so much!

Your work made #648 possible. It is my hope that once that is resolved, Scryer Prolog will be included in the table, yielding good publicity for the system.