:! (bang) and system() are not interactive

[Tranquility]

If I type !git add -p it loops over the output and only stops if i press ctrl-c.

[tarruda]

This is not a bug, it is the new behavior of bang commands: We no longer spawn the program with it's stdout connected to Nvim tty, instead we open a pipe, read output and display to the user. This is the only way the bang commands will be consistent across UIs, so programs designed to be used interactively from the terminal will no longer work from inside nvim.

There are two alternatives for bang commands that behave differently when opened from terminals:

• Invoke it from a shell(either from a different terminal or with ctrl+z)
• Use the fugitive git plugin

[Tranquility]

@tarruda fugitive is the reason I experienced the bug. I am in the status window (:GStatus) and press p on a line to stage/unstage it.

[tarruda]

@tarruda fugitive is the reason I experienced the bug. I am in the status window (:GStatus) and press p on a line to stage/unstage it.

Ok, I had never used the p mapping, thats why I didn't experience this bug(I always use :Gdiff to stage changes in split buffers).

Unfortunately there's not much I can do to help, this is a consequence of Nvim's client-server architecture which can't cope with programs being spawned in the main process tty.

It seems interactive-bang commands is a popular feature(you are not the first to report this behavior), I'm starting to think it's better to find a solution to that soon.

[elmart]

I also think a solution for this should be looked for, if possible. It's not a big deal, specially taking into account what is given in exchange. But it will for sure annoy many people, cause it will break their habits. So, if something can be done, we should strive for it.

[tarruda]

I also think a solution for this should be looked for, if possible. It's not a big deal, specially taking into account what is given in exchange. But it will for sure annoy many people, cause it will break their habits. So, if something can be done, we should strive for it.

A possible solution crossed by mind: A "bang command provider", which would be responsible for running non-filtered shell commands.

Such a provider could be implemented as a python plugin for example, using a newly spawned window/buffer as a terminal emulator. Since there are many ready to use terminal emulation libraries for python, the plugin part should be relatively easy to accomplish. Though I'm still not sure if we have a way to redirect every keypress in a buffer/window to a user function.

[ZyX-I]

On November 19, 2014 11:43:57 PM EAT, Thiago de Arruda notifications@github.com wrote:

I also think a solution for this should be looked for, if possible.
It's not a big deal, specially taking into account what is given in
exchange. But it will for sure annoy many people, cause it will break
their habits. So, if something can be done, we should strive for it.

A possible solution crossed by mind: A "bang command provider", which
would be responsible for running non-filtered shell commands.

Such a provider could be implemented as a python plugin for example,
using a newly spawned window/buffer as a terminal emulator. Since there
are many ready to use terminal emulation libraries for python, the
plugin part should be relatively easy to accomplish. Though I'm still
not sure if we have a way to redirect every keypress in a buffer/window
to a user function.

---

Reply to this email directly or view it on GitHub:
#1496 (comment)

You may want to check out how GVim copes with this problem for any insights. Also getchar(): both take all of the input. Though I think just CTRL-D and CTRL-C mappings and InsertCharPre event are enough, so I would not be sure that you need to redirect every keypress.

[splinterofchaos]

A possible solution crossed by mind: A "bang command provider"

I don't like it. Old behaviour: vim stops rendering the screen and lets the process take over stdin/out. Provider behaviour with UI: UI captures input and sends it to nvim through feedkeys, we forward it to the bang provider, it produces some output and sends it to us, we forward it to the UI in a way it'll understand. Seems like a lot of back-and-forth, especially if the UI implements the bang provider (which would be a smart move, IMO).

But it's easy to criticise; I can't think of a better solution.

[tarruda]

You may want to check out how GVim copes with this problem for any insights.

I've already seen it: It spawns a PTY on supported systems, though as :h gui-pty explains, the feature is incomplete and not portable(also reason why I choose not to maintain this on Nvim)

Also getchar(): both take all of the input. Though I think just CTRL-D and CTRL-C mappings and InsertCharPre event are enough, so I would not be sure that you need to redirect every keypress.

Allowing the user receive every keypress would mean user-defined modes are possible, which would be more powerful for implementing something as complex as a terminal emulators(or any program that runs with a buffer as UI). I will have a look at implementing this later.

I don't like it. Old behaviour: vim stops rendering the screen and lets the process take over stdin/out. Provider behaviour with UI: UI captures input and sends it to nvim through feedkeys, we forward it to the bang provider, it produces some output and sends it to us, we forward it to the UI in a way it'll understand. Seems like a lot of back-and-forth, especially if the UI implements the bang provider (which would be a smart move, IMO).

But it's easy to criticise; I can't think of a better solution.

While there's a lot more processing than with direct pty inheritance, the delay may not be so visible to the user, especially an implementation that buffers output and only displays to the user with a minimal time interval