Read prompt bug?

[Paulo Moura]

Hi,

The documentation of the prompt/2 built-in predicate claims that "A prompt is printed if one of the read predicates is called and the cursor is at the left margin." But:

?- prompt(P, P).
P = '|: '.

?- write('prompt: '), read(A), write('prompt: '), read(B), write('prompt: '), read(C).
prompt: a.
prompt: |: b.
prompt: |: c.

For the three read/1 calls above, the cursor is never at the left margin. But we only get the default prompt omitted for the first read/1 call. Is this a bug or am I misinterpreting at "left margin" means?

Cheers,
Paulo

-----------------------------------------------------------------
Paulo Moura
Logtalk developer

[Jan Wielemaker]

On 1/18/19 1:14 PM, Paulo Moura wrote:
> Hi,
>
> The documentation of the prompt/2 built-in predicate claims that "A prompt is printed if one of the read predicates is called and the cursor is at the left margin." But:
>
> ?- prompt(P, P).
> P = '|: '.
>
> ?- write('prompt: '), read(A), write('prompt: '), read(B), write('prompt: '), read(C).
> prompt: a.
> prompt: |: b.
> prompt: |: c.
>
> For the three read/1 calls above, the cursor is never at the left margin. But we only get the default prompt omitted for the first read/1 call. Is this a bug or am I misinterpreting at "left margin" means?

I did a little search. What happens is this:

- write('prompt: ') --> linepos = 8
- read(A) --> not at left margin: no prompt
--> BUT, according to the ISO standard, the
newline following the term is NOT read
--> linepos = 10 (assuming the user types "a.")
- write('prompt: ') --> linepos = 18
- read(B) --> first reads pending newline --> linepos = 0
Now at left margin: prompt

I think we had a discussion before on something related let to some hack
to make the toplevel behave more sensible.

I do not see a really good solution. One might be to ignore ISO and
read the blank following a term if the input is a terminal?

Using line editing though, just writing the prompt does not work as
the line editor thinks the cursor is at the left margin.

SWI-Prolog has a little bit oddly called predicate prompt1(+Text) that
avoids these problems.

Cheers --- Jan

[Paulo Moura]

Hi Jan,

Thanks for the quick reply. Your explanation was also my guess. Thanks for confirming. The issue occurs when using Logtalk's question asking mechanism (which is the dual of the message printing mechanism). This mechanism allows the user to define the prompt to be used for a question. That's where the default prompt gets in the way. It's mostly an annoying esthetic issue. But one that I have been unable to solve in a portable way so far.

Cheers,
Paulo

[Jan Wielemaker]

On 18/01/2019 16:05, Paulo Moura wrote:
> Thanks for the quick reply. Your explanation was also my guess.
> Thanks for confirming. The issue occurs when using Logtalk's question
> asking mechanism (which is the dual of the message printing
> mechanism). This mechanism allows the user to define the prompt to be
> used for a question. That's where the default prompt gets in the way.
> It's mostly an annoying esthetic issue. But one that I have been
> unable to solve in a portable way so far.

I guess you have little choice but to abstract away and deal with it
in the portability layer. Just writing a prompt has never been a
good idea. Both for readline and libedit you pass the prompt at
an argument to the line reading function.

I guess it is already hookable to deal with web or GUI applications?

Cheers --- Jan

[Paulo Moura]

Hi Jan,

> On 19 Jan 2019, at 17:24, Jan Wielemaker <j...@swi-prolog.org> wrote:
>
> On 18/01/2019 16:05, Paulo Moura wrote:
>> Thanks for the quick reply. Your explanation was also my guess.
>> Thanks for confirming. The issue occurs when using Logtalk's question
>> asking mechanism (which is the dual of the message printing
>> mechanism). This mechanism allows the user to define the prompt to be
>> used for a question. That's where the default prompt gets in the way.
>> It's mostly an annoying esthetic issue. But one that I have been
>> unable to solve in a portable way so far.
>
> I guess you have little choice but to abstract away and deal with it
> in the portability layer.

I ended up using conditional compilation directives to turn off the default prompt (using the built-in prompt/2 predicate) when running on SWI-Prolog or SICStus Prolog. Using these directives is never my preferred solution but in this case there was little choice. Portable code is used for the other supported Prolog compilers.

> Just writing a prompt has never been a
> good idea. Both for readline and libedit you pass the prompt at
> an argument to the line reading function.
>
> I guess it is already hookable to deal with web or GUI applications?

It is, in a similar way to message question mechanism:

https://logtalk.org/manuals/refman/methods/question_hook_6.html

The question hook is usually used when testing (e.g. providing automated answers that replace what the user could have typed or for switching between command-line and GUI interfaces).

Thanks for following up.

Cheers,
Paulo