tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: namespace pollution by curses



I committed it:
http://mail-index.netbsd.org/source-changes/2019/03/14/msg104294.html

Also, pullup requests were sent as [pullup-8 #1214] and [pullup-7 #1686]:
https://releng.netbsd.org/cgi-bin/req-8.cgi?show=1214
https://releng.netbsd.org/cgi-bin/req-7.cgi?show=1686

Thank you everyone for discussion!

rin

On 2019/03/13 7:09, Brett Lymn wrote:
Probably all the state should be gathered up and put into _screen but that does not have to be done right now.  Rin's fix will make aspell work which is a win already.

I am not so sure that our curses is multi-thread safe in a lot of areas.  I think that multiple terminals controlled by curses is allowed for but  I have never tested it and I wouldn't be surprised if it failed spectacularly.



    ----- Original Message -----
    From:
    "Valery Ushakov" <uwe%stderr.spb.ru@localhost>

    To:
    <tech-userlevel%netbsd.org@localhost>
    Cc:
    "Brett Lymn" <blymn%internode.on.net@localhost>, "Rin Okuyama" <rokuyama.rk%gmail.com@localhost>
    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



Home | Main Index | Thread Index | Old Index