lynx-dev unwanted prompt typeahead (was Bug Report - Lynx/2.8.2rel.1)

[Klaus Weide]

On Sun, 1 Aug 1999, Charles Gregory wrote:

> Greetings!
> 
> A small bug in Lynx/2.8.2rel.1 libwww-FM/2.14
> 
> When returning to Lynx after executing an external program, such as PINE
> or TIN, if extraneous characters are entered *before* the user preses
> <return> at the prompt:
> 
> "Press <return> to return to Lynx."

I suppose that means this is about "lynxexec:" URLs.

> Then *some* of those characters are being held in the Lynx input buffer
> and being processed as lynx single-keystroke commands after control
> returns to Lynx. 

I notice something similar yet different.  The difference may be because
I have compiled lynx with slang.

I have the following in a Jump file:

<dt>GMT<dd><a href="lynxexec:/bin/date --rfc-822 --utc" TITLE="gmt: current 
time in GMT">date and t
+ime in GMT</a>

I run this (by typing 'J', "gmt", <return>), output appears, the
"Press <return> to return to Lynx." appears.

If I enter anything more than just <return>, i.e. some extra character
(space does it) and then <return>, the following happens:  the extra
characters are not "processed as lynx single-keystroke commands".
But on re-executing the Jump (typing 'J', "gmt", <return> again),
the command runs, produces output, and the "Press <return>..." prompt
appears but lynx immediately repaints the screen without waiting.
So that the command output & prompt cannot really be read; I used
strace to verify that they do get written.)

Entering several extraneous characters before the <return> seems
to queue them: the number of characters equals the number of following
reads that are skipped.

I notice similar behavior for the "Print to the screen" Printing Option.
But it applies only to the prompt _after_ the page has been "printed".
The other prompts (before "printing" starts) are not affected.

It seems the LYgetch() calls done while curses mode is off act
differently, effectively input is queued and this queue is separate
from what is used in curses mode.  And the queue survives across
"curses mode on" periods, which it shouldn't.

> It appears that the input procedure associated with the 'return' prompt is
> invoking the 'read terminal until CR' function but only discards *one*
> character from the input buffer. You need to flush the bufer.

I'm nut sure where the buffer is, it may be just stdio buffering, and it
seems to be different between (n)curses and slang.

   Klaus