po 22. 3. 2021 v 13:13 odesÃlatel Thomas Munro <thomas.mu...@gmail.com>
napsal:
> On Mon, Mar 22, 2021 at 5:10 PM Pavel Stehule <pavel.steh...@gmail.com>
> wrote:
> > probably there will not be an issue inside ncurses - the most complex
> part of get_event is polling of input sources - tty and some other. The
> pspg should not to stop there on tty reading.
>
> The problem is that Apple's /dev/tty device is defective, and doesn't
> work in poll(). It always returns immediately with revents=POLLNVAL,
> but pspg assumes that data is ready and tries to read the keyboard and
> then blocks until I press a key. This seems to fix it:
>
> +#ifndef __APPLE__
> + /* macOS can't use poll() on /dev/tty */
> state.tty = fopen("/dev/tty", "r+");
> +#endif
> if (!state.tty)
> state.tty = fopen(ttyname(fileno(stdout)), "r");
>
it is hell.
Please, can you verify this fix?
> A minor problem is that on macOS, _GNU_SOURCE doesn't seem to imply
> NCURSES_WIDECHAR, so I suspect Unicode will be broken unless you
> manually add -DNCURSES_WIDECHAR=1, though I didn't check.
>
It is possible -
can you run "pspg --version"
[pavel@localhost pspg-master]$ ./pspg --version
pspg-4.4.0
with readline (version: 0x0801)
with integrated menu
ncurses version: 6.2, patch: 20200222
ncurses with wide char support
ncurses widechar num: 1
wchar_t width: 4, max: 2147483647
with inotify support
This is not too critical for pspg, because all commands are basic ascii
chars. Strings are taken by readline library or by wgetnstr function
