Those fifos are accessible during %sh{...} blocks, the command fifo
executes commands written to it once the write end side is closed
(multiple open/write/close sequences are supported), the response
fifo is a simple helper fifo available to write response back to
the shell process
An example use of this feature is to request some list options
content from without being limited by the environment size:
```
%sh{
echo "echo -to-file $kak_response_fifo -quoting shell -- %opt{some_list}" > $kak_command_fifo
eval "set -- $(cat $kak_response_fifo)"
}
```
This avoids 100% CPU usage when we have pending fifo input while running
a shell process, as we will not end-up busy looping in pselect but not
reading the available data due to being only processing urgent events.
Handle next event should never block if we have already accumulated
input that we want to process. As we can accumulate new input in
lots of places (everytime we run a shell process for example, we
might end up reading input keys. That can be triggered during the
mode line generation which takes place during display of the window)
Fixes#1804
This round trip through an input callback expected to call
is_key_available and get_key was overcomplicated, just send the
keys as they arrive, the client is already buffering due to urgent
event mode.
Use a wrapper for sigaction in place of signal to ensure that the
SA_RESTART flag is set for all signals used.
Signed-off-by: Daniel Robertson <danlrobertson89@gmail.com>
If an event handler add or removes an event from the manager, it may then
be moved in the vector, and if after that it access any of it's members
(through this), it results in an invalid memory access.
