Neovim interferes with mutt #2086
Comments
|
It might be related but it isn't the same problem. All of those bugs manifest when running commands inside of neovim while this problem shows up after neovim has exited. Basically, mutt is giving control of the terminal to neovim and then neovim doesn't appear to be giving full control back when it exits. |
|
@Stebalien can you tell me if this patch helps? diff --git a/src/nvim/tui/tui.c b/src/nvim/tui/tui.c
index cdea867..3e749e0 100644
--- a/src/nvim/tui/tui.c
+++ b/src/nvim/tui/tui.c
@@ -2,6 +2,9 @@
#include <stdbool.h>
#include <stdio.h>
+#include <termios.h>
+#include <sys/ioctl.h>
+
#include <uv.h>
#include <unibilium.h>
@@ -36,7 +39,8 @@ typedef struct {
TermInput *input;
uv_loop_t *write_loop;
unibi_term *ut;
- uv_tty_t output_handle;
+ struct termios orig_termios;
+ uv_pipe_t output_handle;
uv_signal_t winch_handle;
Rect scroll_region;
kvec_t(Rect) invalid_regions;
@@ -114,10 +118,19 @@ void tui_start(void)
// setup output handle in a separate event loop(we wanna do synchronous
// write to the tty)
+ tcgetattr(data->out_fd, &data->orig_termios);
+ struct termios new_termios = data->orig_termios;
+ new_termios.c_iflag &= ~(unsigned)(BRKINT | ICRNL | INPCK | ISTRIP | IXON);
+ new_termios.c_oflag |= (ONLCR);
+ new_termios.c_cflag |= (CS8);
+ new_termios.c_lflag &= ~(unsigned)(ECHO | ICANON | IEXTEN | ISIG);
+ new_termios.c_cc[VMIN] = 1;
+ new_termios.c_cc[VTIME] = 0;
+ tcsetattr(data->out_fd, TCSADRAIN, &new_termios);
data->write_loop = xmalloc(sizeof(uv_loop_t));
uv_loop_init(data->write_loop);
- uv_tty_init(data->write_loop, &data->output_handle, data->out_fd, 0);
- uv_tty_set_mode(&data->output_handle, UV_TTY_MODE_RAW);
+ uv_pipe_init(data->write_loop, &data->output_handle, 0);
+ uv_pipe_open(&data->output_handle, data->out_fd);
// Obtain screen dimensions
update_size(ui);
@@ -174,7 +187,7 @@ static void tui_stop(UI *ui)
// Disable bracketed paste
unibi_out(ui, (int)data->unibi_ext.disable_bracketed_paste);
flush_buf(ui);
- uv_tty_reset_mode();
+ tcsetattr(data->out_fd, TCSANOW, &data->orig_termios);
uv_close((uv_handle_t *)&data->output_handle, NULL);
uv_run(data->write_loop, UV_RUN_DEFAULT);
if (uv_loop_close(data->write_loop)) {
@@ -596,7 +609,10 @@ static void update_size(UI *ui)
TUIData *data = ui->data;
int width = 0, height = 0;
// 1 - try from a system call(ioctl/TIOCGWINSZ on unix)
- if (!uv_tty_get_winsize(&data->output_handle, &width, &height)) {
+ struct winsize ws;
+ if (!ioctl(data->out_fd, TIOCGWINSZ, &ws)) {
+ width = ws.ws_col;
+ height = ws.ws_row;
goto end;
} |
|
Sorry, it doesn't make a difference (thanks for the quick response however). |
|
@Stebalien What version of mutt do you use? It works fine for me (neovim compiled today, mutt 1.5.23 [which may be a bit outdated] on F21 using urxvt). |
|
Same versions here. Mutt 1.5.23, neovim commit 6b7ece6. |
|
Yup, I'm on the same commit. Did you try to compile neovim without AUR? I honestly have no idea how far AUR can customize the process, but that would be my next step. |
|
I tried both. I am using a patched kernel (grsecurity) but that shouldn't be causing this problem. -- Edit: Disabling grsecurity doesn't fix the bug. |
|
I am also experiencing the same behavior as @Stebalien. Arch Linux |
|
I reinstalled fedora 21 today and I experience the same issue now, additionally I can't postpone or abort the message or open the pgp menu. Imho thats really strange, since it is basically the same software aside from that I installed Fedora 21 Workstation now, while I had beend using an upgraded version of Fedora 21 beta. |
|
I'm having a similar problem with the code review tool that we use: Arcanist. It seems to occur when something would prompt you for a value after you exit the editor. When I run this for arcanist, I get the following result: It never actually lets me answer the prompt, though, and goes straight to the default option. I think can reproduce this behaviour with the following simple shell file: # /Users/drew/testnvim
nvim /tmp/whatever
read -p "Reading a value: " valueThis produces the following result: I see that that same |
|
I'm suffering from this bug, too. |
|
Here is a strace after I've written the message and getting ready to hit the 'p' key in mutt. We can see that mutt is trying to write the menu (it works the same with q), and every once in a while, you can see something pop up on the status line. #2076 doesn't work. Same behavior is exhibited. (Ends with me sending SIGHUP) select(1, [0], NULL, NULL, {5, 0}) = 0 (Timeout) |
|
@Stebalien @ntnn @ryanmorillo @bigeagle #2598 may fix this issue if you want to try. |
|
@justinmk Works like a charm, awesome work! |
If stdin is non-blocking, many tools (e.g. cat(1), read(1)) which assume that stdin is blocking, will break in odd ways: read: read error: 0: Resource temporarily unavailable cat: -: Resource temporarily unavailable rm: error closing file libuv puts stdin in nonblocking mode, and leaves it that way at exit (this is apparently by design). So, before this commit, this always works (because the shell clobbers O_NONBLOCK): $ nvim --cmd q $ read ...but these forms do _not_ work: $ nvim --cmd q && read $ echo foo | nvim --cmd q && read $ nvim && read After this commit, all of the above forms work. Background: fish-shell/fish-shell@437b439#diff-41f4d294430cd8c36538999d62681ae2 fish-shell/fish-shell#176 (comment) - bash (and other shells: zsh, tcsh, fish), upon returning to the foreground, always sets fd 0 back to blocking mode. This practice only applies to stdin, _not_ stdout or stderr (in practice these fds may be affected anyways). - bash/zsh/tcsh/fish do _not_ restore the non-blocking status of stdin when _resuming a job_. - We do _not_ save/restore the original flags visible to fcntl(F_[SG]ETFL), because (counterintuitively) that isn't expected. Helped-by: oni-link <knil.ino@gmail.com> Closes neovim#2086 Closes neovim#2377
If stdin is non-blocking, many tools (e.g. cat(1), read(1)) which assume that stdin is blocking, will break in odd ways: read: read error: 0: Resource temporarily unavailable cat: -: Resource temporarily unavailable rm: error closing file libuv puts stdin in nonblocking mode, and leaves it that way at exit (this is apparently by design). So, before this commit, this always works (because the shell clobbers O_NONBLOCK): $ nvim --cmd q $ read ...but these forms do _not_ work: $ nvim --cmd q && read $ echo foo | nvim --cmd q && read $ nvim && read After this commit, all of the above forms work. Background: fish-shell/fish-shell@437b439#diff-41f4d294430cd8c36538999d62681ae2 fish-shell/fish-shell#176 (comment) - bash (and other shells: zsh, tcsh, fish), upon returning to the foreground, always sets fd 0 back to blocking mode. This practice only applies to stdin, _not_ stdout or stderr (in practice these fds may be affected anyways). - bash/zsh/tcsh/fish do _not_ restore the non-blocking status of stdin when _resuming a job_. - We do _not_ save/restore the original flags visible to fcntl(F_[SG]ETFL), because (counterintuitively) that isn't expected. Helped-by: oni-link <knil.ino@gmail.com> Closes neovim#2086 Closes neovim#2377
If stdin is non-blocking, many tools (e.g. cat(1), read(1)) which assume that stdin is blocking, will break in odd ways: read: read error: 0: Resource temporarily unavailable cat: -: Resource temporarily unavailable rm: error closing file libuv puts stdin in nonblocking mode, and leaves it that way at exit (this is apparently by design). So, before this commit, this always works (because the shell clobbers O_NONBLOCK): $ nvim --cmd q $ read ...but these forms do _not_ work: $ nvim --cmd q && read $ echo foo | nvim --cmd q && read $ nvim && read After this commit, all of the above forms work. Background: fish-shell/fish-shell@437b439#diff-41f4d294430cd8c36538999d62681ae2 fish-shell/fish-shell#176 (comment) - bash (and other shells: zsh, tcsh, fish), upon returning to the foreground, always sets fd 0 back to blocking mode. This practice only applies to stdin, _not_ stdout or stderr (in practice these fds may be affected anyways). - bash/zsh/tcsh/fish do _not_ restore the non-blocking status of stdin when _resuming a job_. - We do _not_ save/restore the original flags visible to fcntl(F_[SG]ETFL), because (counterintuitively) that isn't expected. Helped-by: oni-link <knil.ino@gmail.com> Closes neovim#2086 Closes neovim#2377 --- Note: The following implementation of stream_set_blocking() was discarded, because it resulted in a failed libuv assertion[1]: int stream_set_blocking(int fd, bool blocking) { uv_pipe_t stream; uv_pipe_init(uv_default_loop(), &stream, 0); uv_pipe_open(&stream, fd); int retval = uv_stream_set_blocking((uv_stream_t *)&stream, blocking); uv_close((uv_handle_t *)&stream, NULL); return retval; } [1] .deps/build/src/libuv/src/unix/core.c:833: uv__io_stop: Assertion `loop->watchers[w->fd] == w' failed.
If stdin is non-blocking, many tools (e.g. cat(1), read(1)) which assume that stdin is blocking, will break in odd ways: read: read error: 0: Resource temporarily unavailable cat: -: Resource temporarily unavailable rm: error closing file libuv puts stdin in nonblocking mode, and leaves it that way at exit (this is apparently by design). So, before this commit, this always works (because the shell clobbers O_NONBLOCK): $ nvim --cmd q $ read ...but these forms do _not_ work: $ nvim --cmd q && read $ echo foo | nvim --cmd q && read $ nvim && read After this commit, all of the above forms work. Background: fish-shell/fish-shell@437b439#diff-41f4d294430cd8c36538999d62681ae2 fish-shell/fish-shell#176 (comment) - bash (and other shells: zsh, tcsh, fish), upon returning to the foreground, always sets fd 0 back to blocking mode. This practice only applies to stdin, _not_ stdout or stderr (in practice these fds may be affected anyways). - bash/zsh/tcsh/fish do _not_ restore the non-blocking status of stdin when _resuming a job_. - We do _not_ save/restore the original flags visible to fcntl(F_[SG]ETFL), because (counterintuitively) that isn't expected. Helped-by: oni-link <knil.ino@gmail.com> Closes neovim#2086 Closes neovim#2377 --- Note: The following implementation of stream_set_blocking() was discarded, because it resulted in a failed libuv assertion[1]: int stream_set_blocking(int fd, bool blocking) { uv_pipe_t stream; uv_pipe_init(uv_default_loop(), &stream, 0); uv_pipe_open(&stream, fd); int retval = uv_stream_set_blocking((uv_stream_t *)&stream, blocking); uv_close((uv_handle_t *)&stream, NULL); return retval; } [1] .deps/build/src/libuv/src/unix/core.c:833: uv__io_stop: Assertion `loop->watchers[w->fd] == w' failed.
If stdin is non-blocking, many tools (e.g. cat(1), read(1)) which assume that stdin is blocking, will break in odd ways: read: read error: 0: Resource temporarily unavailable cat: -: Resource temporarily unavailable rm: error closing file libuv puts stdin in nonblocking mode, and leaves it that way at exit (this is apparently by design). So, before this commit, this always works (because the shell clobbers O_NONBLOCK): $ nvim --cmd q $ read ...but these forms do _not_ work: $ nvim --cmd q && read $ echo foo | nvim --cmd q && read $ nvim && read After this commit, all of the above forms work. Background: fish-shell/fish-shell@437b439#diff-41f4d294430cd8c36538999d62681ae2 fish-shell/fish-shell#176 (comment) - bash (and other shells: zsh, tcsh, fish), upon returning to the foreground, always sets fd 0 back to blocking mode. This practice only applies to stdin, _not_ stdout or stderr (in practice these fds may be affected anyways). - bash/zsh/tcsh/fish do _not_ restore the non-blocking status of stdin when _resuming a job_. - We do _not_ save/restore the original flags visible to fcntl(F_[SG]ETFL), because (counterintuitively) that isn't expected. Helped-by: oni-link <knil.ino@gmail.com> Closes neovim#2086 Closes neovim#2377 --- Note: The following implementation of stream_set_blocking() was discarded, because it resulted in a failed libuv assertion[1]: int stream_set_blocking(int fd, bool blocking) { uv_pipe_t stream; uv_pipe_init(uv_default_loop(), &stream, 0); uv_pipe_open(&stream, fd); int retval = uv_stream_set_blocking((uv_stream_t *)&stream, blocking); uv_close((uv_handle_t *)&stream, NULL); return retval; } [1] .deps/build/src/libuv/src/unix/core.c:833: uv__io_stop: Assertion `loop->watchers[w->fd] == w' failed.
|
Should be fixed now, please say if not! |
|
Works for me. Thanks! |
|
Works for me, too. Cheers! On 15-05-27 06:54, Steven Allen wrote:
Justin Wong Blog: https://bigeagle.me/ |
|
Works for me too. |
I have to change my editor in mutt until neovim/neovim#2086 (comment) is fixed. Neovim is sending some characters to stdout, which is preventing some applications that rely on keys being sent afterwards from functioning correctly. Vim works just fine for these, though.
It's impossible to add attachments (
a) or abort a message (q) in mutt after composing a message with neovim. To reproduce, runEDITOR=nvim mutt, hitmto compose a message, type in a random email address, type in a random subject, write a random body into neovim, save and quite neovim, and then try theaandq(mutt) commands (send,y, works fine).This happens on every terminal I have tried (termite, urxvt, a linux virtual terminal) and with a clean mutt/neovim configs and vim doesn't cause this bug.
I'm running Arch Linux (using the neovim-git package from the AUR) if in case that helps.
Here is an strace snippet starting from when I saved the message in neovim and ending where I closed my terminal.
Note: The "Postpone this message?" prompt present in this trace is never displayed.
The text was updated successfully, but these errors were encountered: