Apologies for the multi-list posting, but I think this needs a wide
audience - please respect the Reply-To and send replies only to
current-users@
I have been looking into this, a little.
First, while the t_mlock() test is most likely broken, it
should never cause a kernel panic (or even a
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
On Tue, Mar 12, 2019 at 15:21:49 -, Christos Zoulas wrote:
> In article <20190312134722.ga1...@netbsd.org>,
> David Holland wrote:
> >On Tue, Mar 12, 2019 at 01:25:13PM +0300, Valery Ushakov wrote:
> > > Admittedly, I'm not sure about the usage. E.g. in wscons case you can
> > > press a
In article <20190312134722.ga1...@netbsd.org>,
David Holland wrote:
>On Tue, Mar 12, 2019 at 01:25:13PM +0300, Valery Ushakov wrote:
> > 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
On Tue, Mar 12, 2019 at 01:25:13PM +0300, Valery Ushakov wrote:
> 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
On 2019/03/12 10:11, Brett Lymn wrote:
(sorry for the top post...)
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
