Re: q for quit in plot windows

[<tim...@en...>]

>>> 'q' and ' ' should work as they are. It is sufficient and a very clean
>>> way
>>> to switch them on/off by a term->xxxx() command I proposed earlier.
>>
>>> Then you mean that "bind" command should work always to all screen
>>> terminals. Then it seems to be even more easily coded:
>>
>> There is a problem with moving ' ' or 'q' into the general "bind"
>> mechanism, and the same problem applies to extending "bind all"
>> to handle multiple active terminal types.
>
> I proposed this bind mechanism for the 2 hotkeys:
> - on -- the current built-in: gnuplot_x11 or gnupmdrv.exe etc. execute the
>   'q' and ' '
> - off -- planned: these hotkeys will be passed from gnuplot_x11 etc into
>   gnuplot as all the other keys
>

I doubt it's the right fix:

1) It already exists in the form of the ctrl-q option in x11 and wxt
2) This is doomed to be completely opaque to the user, as is the current
ctrl-q solution in my opinion
3) It doesn't really fix the problem (again, this problem is that we
cannot listen to events coming from different terminals at the same time
in the current design), but only workaround it with a new option...


>
>> How much would it take to make gnuplot look for events from all
>> terminals
>> it has accessed?  If gnuplot initializes a terminal, it can put that
>> pointer on a linked list (could use dynarray).  Then go through the list
>> looking for events.
>>  Or is there more to switching terminals in that regard?
>
> This "listen all the time" works on OS/2 (thread + shared memory is used,
> not waitforinput), but if pm is not the current terminal, then the
> commands
> like grid, log etc. are replotted for the other selected terminal.
>

Yes, we need to extend and unify _cleanly_ this "listen all the time"
behaviour between all platforms and several terminals at a time, and nuke
term->waitforinput

Timothée