This reverts commit ab8371a26c.
Need to think of a different solution, which may require adding new
flags to nvim_ui_attach() (e.g. passing stdout or stderr fd).
Problem: If Nvim server fails to --listen and prints error before the
TUI enters alternate screen, the error isn't visible.
Solution: Forward server stderr using client side stderr handler instead
of having the server inherit client stderr file descriptor.
This does mean that `stderr_isatty` will be `false` in the server, but
that value doesn't matter in embedded mode.
Always pass `stdin_fd` to embedded server to avoid a hang when reading
from stdin when it's a TTY (not sure why one wants to do that, perhaps
by mistake), because if `stdin_fd` isn't passed, the server will try to
use stderr as stdin.
Example test failure on CI:
FAILED test/functional/terminal/tui_spec.lua @ 41: TUI exit status 1 and error message with server --listen error #34365
test/functional/terminal\tui_spec.lua:55: Failed to match any screen lines.
Expected (anywhere): "nvim%.exe: Failed to %-%-listen: address already in use:"
Actual:
|{114:nvim.exe -h"} |
| |
|[Process exited 1]^ |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
|{5:-- TERMINAL --} |
Snapshot:
screen:expect([[
{114:nvim.exe -h"} |
|
[Process exited 1]^ |
|*13
{5:-- TERMINAL --} |
]])
stack traceback:
test\functional\ui\screen.lua:909: in function '_wait'
test\functional\ui\screen.lua:537: in function 'expect'
test/functional/terminal\tui_spec.lua:55: in function <test/functional/terminal\tui_spec.lua:41>
In this case, it appears that the client entered alternate screen in the
middle of the server's print_mainerr().
Problem: Terminal doesn't detect if the PTY process is suspended or
offer a convenient way for the user to resume the process.
Solution: Detect suspended PTY process on SIGCHLD and show virtual text
"[Process suspended]" at the bottom-left. Resume the process
when the user presses a key.
These are not needed after #35129 but making uncrustify still play nice
with them was a bit tricky.
Unfortunately `uncrustify --update-config-with-doc` breaks strings
with backslashes. This issue has been reported upstream,
and in the meanwhile auto-update on every single run has been disabled.
Problem:
- "process" is often used as a verb (`multiqueue_process_events`), which
is ambiguous for cases where it's used as a topic.
- The documented naming convention for processes is "proc".
- `:help dev-name-common`
- Shorter is better, when it doesn't harm readability or
discoverability.
Solution:
Rename "process" => "proc" in all C symbols and module names.