Re: "pause mouse close" almost works, but not completely

[sfeam <sf...@us...>]

On Sunday, 14 October 2018 14:46:40 Dima Kogan wrote:
> sfeam <sf...@us...> writes:
> 
> > x11:  In theory a terminal driver can see the window close event either
> >       as a GE_keypress event with the 1st parameter set to GP_Cancel
> >       or as a GE_reset event.  x11 handled the first case but failed to
> >       catch the second case.  Patch below.
> 
> Thank you very much. This patch fixes the bulk of the problem. There's
> still a small vestige of the previous incorrect behavior that maybe is
> unimportant, but I'll mention it anyway.
> 
> 1. Run gnuplot
> 2. plot x
> 3. pause mouse close
> 4. 'q' in the popped-up terminal window. This gets us back to a
>    "gnuplot>" prompt
> 5. If you start typing into THIS new prompt, you get a SECOND gnuplot>
>    prompt to type into. Presumably the select() in the gnuplot process
>    is still waiting for some data from the gnuplot_x11 helper that
>    doesn't exist anymore

That is a consequence of a fix/hack/work-around that was added to mouse.c
a long time ago.  See lines starting with 2323 in mouse.c.

The original problem was that if you used the "pause mouse key" command
from a script, i.e. gnuplot was taking input from a pipe, then the first
character of the subsequent command was lost.  This generated an error
because usually losing the first character of a valid command leaves
an invalid command.  One fix is to add an extra blank line or at least
and extra blank character in the script file.  The cleaner fix seemed
to be to add back a harmless character '\n' in the mouse handling, which
could then be lost or not lost with no harm done.

It is possible that this recent set of fixes may have had the side effect
of also fixing the original lose-the-next-character bug.  So what you are
seeing is the added '\n' that was the work-around for a bug that may no
longer be present.

Commenting out the code block as mouse.c:2323 will get rid of the extra
prompt you are seeing.  That may or may not restore the problem of losing
character with piped input - it needs to be tested.

	Ethan