Re: namespace pollution by curses

["Brett Lymn" <blymn%internode.on.net@localhost>]

IIUC I think the intention was to have multiple serial terminals and
be able to control each one via curses which would mean the keyboard
input would be only coming from a single device at a time not
interleaving input from all of them.  I don't really have any
experience with multiple keyboards in wscons but my naive
interpretation is that there is a single multiplexed device that
combines all the inputs but also you can read the individual devices
too if you open the right device? (e.g. /dev/wsmouse vs
/dev/wsmouse0) 

----- Original Message -----
From: "Valery Ushakov" 
To:
Cc:"Brett Lymn" , "Rin Okuyama" 
Sent:Tue, 12 Mar 2019 13:25:13 +0300
Subject:Re: namespace pollution by curses

 On Tue, Mar 12, 2019 at 11:41:39 +1030, Brett Lymn wrote:

 > I am happy with either the rename of the static definition or
 > including the state variable in _cursesi_screen which already holds
 > the tty information anyway.  Mind you, if you put the state
variable
 > into _cursesi_screen then you may get the situation that someone
 > swtiches screens part way through a multi-character key sequence
which
 > will result in a partial escape sequence being delivered to the new
 > screen which is unlikely but undesirable.  If we stick with the
 > static variable then the worst that happens is the assembled key
code
 > will be delivered to the new screen.
 >
 > To be honest, I think the screen switching scenario is so unlikely
 > that putting the variable there would be fine.

 Doesn't that just mean that inbuf &c should be in __screen too? As I
 said, since infd is in __screen, shouldn't everything down the data
 path be also per screen?

 Admittedly, I'm not sure about the usage. E.g. in wscons case you can
 press a modifier on one keyboard and the key on another and it should
 work. But in case of curses, do the users really expect to be able to
 input the beginning of a multi-byte sequence on one screen (via that
 screen-private infd) and the end of if on another screen (via its own
 screen-private infd) and still get a composed (via static
 state/inbuf/...) wide character sent to the second screen?

 -uwe