Re: wait does not perform as expected

[Niklas Holsti <niklas.holsti@tidorum.invalid>]

On 2023-02-24 17:10, AdaMagica wrote:
> Dmitry A. Kazakov schrieb am Donnerstag, 23. Februar 2023 um 21:41:16 UTC+1:
>> It is to expect it to work with the "standard" terminal [emulator].
>> Anything else is a long shot.
> 
> Right, there may be weird file kinds where Get_Immediate fails.


I would expect Get_Immediate to work on any kind of "file" for which 
isatty() returns 1, meanng "it is a tty".

Interestingly, this is the case for the execution input/output window 
under my GPS: isatty() returns 1, and ttyname() is 
"/dev/tty<something>", but still Get_Immediate requires a <return> 
keystroke before it sees anything as Available.

It seems to me that the natural implementation (on Unix-like systems) of 
Get_Immediate is for it to use isatty() to check if the input file is a 
"tty", and if so to call ioctl() to disable line buffering so that every 
keystroke is delivered immediately. Why that does not work under GPS 
(mine and yours) is not clear to me.


> Niklas Holsti schrieb am Donnerstag, 23. Februar 2023 um 19:29:36 UTC+1:
>> On my system, if Look_Ahead uses getc and ungetc, it seems Get_Immediate
>> does not use the same buffers, and has no effect on those buffers. That
>> could be desirable behaviour in some cases, undesirable in others.
>>
>> On AdaMagica's system, it seems that Get_Immediate uses the same buffers
>> as Look_Ahead (getc/ungetc).
> 
> I further experimented.
> 
>    loop
>      Get_Immediate (Char, Avl);  Put ("Get_Immediate: '" & Char & "', Available   => " & Avl'Image);  New_Line;
>      delay 1.0;
>    end loop;
> 
> Run in GPS, it behaves strangely (seems to be one of Dmitry's weird files)
> 
> ab c<return>
> Get_Immediate: 'a', Available   => TRUE
> Get_Immediate: 'b', Available   => TRUE
> Get_Immediate: ' ', Available   => TRUE
> Get_Immediate: 'c', Available   => TRUE
> Get_Immediate: '
> ', Available   => TRUE                      long pause until:
> <return>
> Get_Immediate: '
> ', Available   => TRUE
> 
> It only reacts after <return> is pressed.


Under my GPS, it returns Available => False until <return> is pressed, 
and then it returns the characters typed before the <return>, as for 
you. An interesting difference, and somehow it seems to me consistent 
with the difference between our systems in the interaction of 
Get_Immediate and Look_Ahead.


> On a terminal window, the same executable reacts as I expect
> (this is why the delay statement is there).
> 
> Get_Immediate: ' ', Available   => FALSE
> Get_Immediate: ' ', Available   => FALSE
> Get_Immediate: ' ', Available   => FALSE       as long as no <return> is pressed
> a                                                                         note: no <return>
> Get_Immediate: 'a', Available   => TRUE
> Get_Immediate: ' ', Available   => FALSE       and so on.


I see the same behaviour in my terminal window, and this is the 
behaviour I would expect (for Get_Immediate alone, without any 
Look_Ahead calls). It seems that this is also what the OP wants and 
should get, if the OP calls only Get_Immediate and runs in a terminal 
window (and not under GPS).


> Looks to me like the behaviour shown last is the correct one (let
> aside weird terminals).

I agree.


> Niklas, your GNAT is two years older than mine. I guess GNAT has been
> corrected (at least changed) in between.


Quite possible. But the behaviour differences (assuming a terminal 
window) concern only the interaction between normal input (including 
Look_Ahead) and Get_Immediate, which I think is very rarely important. 
However, the behaviour you see, where Get_Immediate inspects the normal, 
as-yet unconsumed input stream, is more in-line with the Ada RM text.


> If we all disagree how it should work, we should post this on Ada
> Comment.

I don't think we disagree: Get_Immediate should return each keystroke 
ASAP, without waiting for a <return>. And the RM text is good, IMO.

However, an enhancement request / minor bug report to AdaCore re the 
<return> dependency of Get_Immediate under GPS could be in order.