Input related issues

[joseluis]

Hey @dankamongmen I thought we could try the new discussions.

I'm started playing with input and I found some unexpected behaviour, and I prefer to ask for your input (pun not intended) before hitting my head any further unnecessarily.

1. NCOPTION_NO_QUIT_SIGHANDLERS doesn't seem to do anything, notcurses still quits with ctrl + c (and the rest of the signals like ctrl+z also works unimpeded)
2. notcurses_getc_nblock() doesn't show the following modifiers in the ncinput structure:
   2.1. the shift key ever gets detected.
   2.2. the ctrl key when sending ctrl + j or ctrl + enter.
3. notcurses_inputready_fd doesn't seem to be necessary at all.

I created a small rust example full-input in case that's useful.

[dankamongmen]

• NCOPTION_NO_QUIT_SIGHANDLERS prevents notcurses from installing fatal signal handlers which restore the terminal, and then propagate the signal. in no case does notcurses configure SIGIGN for signals. see notcurses_init(3).

• yep, we can't detect the shift key with our current technology. i could turn it on when we detected capital letters, but that seems (a) partial and (b) unsafe. your ctrl observation is accurate. see the BUGS section of notcurses_input(3)

• notcurses_inputready_fd's purpose is explained in notcurses_input(3). kinda, anyway. i don't want people poll()ing directly on the input file descriptor for readiness, because of the possibility of reading a partial escape/EGC. instead, i produce an eventfd that they can poll() on, which goes high only when we have processed input at the ready.

grokked?

play around with notcurses-input -- it is up-to-date, AFAIK

[dankamongmen]

regarding signals:

• at process start, we inherit SIGIGN from our parent process; all other handlers are set to SIGDFL by the kernel. see exec(2)
• by default, SIGTERM, SIGINT, SIGSEGV etc drop core and terminate. see signal(7)
• by default, we register fatal_handler for INT/QUIT/SEGV/ABRT/TERM
  • this is what NCOPTION_NO_QUIT_SIGHANDLERS inhibits
  • this is done so that when you crash/ctrl+c/etc, you don't get left with say salmon-on-salmon text that is blinking and writing backwards

fatal_handler():

// this wildly unsafe handler will attempt to restore the screen upon
// reception of SIG{INT, SEGV, ABRT, QUIT, TERM}. godspeed you, black emperor!
static void
fatal_handler(int signo){
  notcurses* nc = atomic_load(&signal_nc);
  if(nc){
    notcurses_stop_minimal(nc);
    if(signal_sa_handler){
      signal_sa_handler(signo);
    }
    raise(signo);
  }
}

it attempts to reset the terminal, and then propagates the original signal. since we registered this handler with SA_RESETHAND, the default handler catches it, we drop core, and terminate, perhaps to see a brighter tomorrow.

[joseluis]

Thank you for the explanations. I understand it better but I'll have to dive deeper in all the C world of signals, and libc...

Do you think it would be possible to offer a simple way from notcurses to make all interrupt, quit, suspend, and flow control characters pass through uninterpreted, instead of generating a signal? like ncurses raw mode. So that they can be treated as normal key combinations by the user's program.

[dankamongmen]

yeah that wouldn't be hard at all. i'm thinking we'd want a new option for notcurses_init(), plus perhaps runtime enable+disable. See #1228.