On Mon, Mar 22, 2021 at 5:10 PM Pavel Stehule <pavel.stehule@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
