Make completions commands more friendly to new users.

[mmalcomson]

A few problems observed:

• INPUTRC could be set in bashrc according to TERM=dumb and vsh_shell_start won't see it.
• Does not automatically complete current word when only one possible-completion (not 100% sure if possible -- need to wait until text is back from subprocess before starting completion and have no real trigger on that happening).
• <C-q> mapping is often captured by the terminal rather than getting sent to vim anyway.
• People expect <TAB> -- I don't want that because I like to indent larger blocks with tab (e.g. python functions in REPL, or larger GDB or shell commands), but that should probably be the default.

[hardenedapple]

I'm deciding to not implement most of this due to the trade-offs involved. None of these decisions are 100% clear.

1. Attempting to pick up INPUTRC set in the users bashrc The obvious way to do this is to directly source the users bashrc and /etc/bash.bashrc from vsh_shell_start.

• These files are supposed to only run in interactive shells, it feels a little troublesome to start sourcing it directly.
• When looking into this I found that I happen to have an early-out in both those files avoiding any behaviour change if not running interactively.
• I'd guess this is a standard practice -- it's at least in the OS provided /etc/bash.bashrc file for me.

The next likely approach seems to be to make the vsh_shell_start script run as if it were interactive. I.e. use #!/bin/bash -i as the shebang. This seems to work, but if there is any text printed out to the user on startup then we would have introduced the possibility of a python stack trace being printed out on the command line. To see this, with the above shebang in vsh_shell_start:

• open some VSH file in one neovim instance (nvim test.vsh)
• in another terminal, start another neovim instance on the same file (nvim test.vsh)
• When queried whether to actually open the file by neovim, press Q to quit.
• Should see a python stack trace on the terminal output.

This seems to do with the behaviour of ftplugin running twice on a file at startup that neovim has. Essentially we end up with some output coming from the started process but with no-where to put it.

There are other observables, like any output that gets printed at bash startup being printed twice (or three times if this is the file opened on the command line) instead of just once.

Overall I think these other changes seem to be less beneficial than accounting for the use case of a user changing INPUTRC in their .bashrc.

---

What I think would be worth it is to allow the user to manually override the detection mechanism in case it's wrong, and have something in their vimrc which says "just use these settings".

---

2. Automatic completion of word on command line. As yet I don't think this is possible, but what does seem possible is to convert the mapping of <TAB> from "get possible-completions to underlying shell" to "<C-n>, and convert it back when a completion has been chosen. That would make <TAB> first get possible completions into the buffer, then start to cycle between them, then when one has been chosen the next <TAB> will send the binding for readline's possible-completions again.

Honestly I just thought this would be too much effort for the benefit. If anyone else comments on this (the OP is just me from another account) then I'll rethink this. If anyone else wants to implement that (with some sort of "opt-out" mechanism in place) I'd be interested.

---

3. Using <TAB> instead of <C-q> seems a good idea -- will do.