Add stdin to subprocess call

[actionshrimp]

On windows I've been seeing errors when using tern omnicomplete. The error is in the tern_startServer function, and the bottom of the stack track looks like this (sorry, I'm not able to capture the full stack trace at the minute, but it's definitely the subprocess.Popen call in tern_startServer where it's happening):

File "C:\dev\cpython\cpython\lib\subprocess.py", line 732, in __init__
  errread, errwrite) = self._get_handles(stdin, stdout, stderr)
File "C:\dev\cpython\cpython\lib\subprocess.py", line 903, in _get_handles
  p2cread = self._make_inheritable(p2cread)
File "C:\dev\cpython\cpython\lib\subprocess.py", line 946, in _make_inheritable
  _subprocess.DUPLICATE_SAME_ACCESS)
WindowsError: [Error 6] The handle is invalid

Googling for the error I've found several other projects that give the same underlying windows error, such as one here: http://bugs.python.org/issue3905 (I am using python 2.7.5, so this doesnt seem to be a 'legacy python' issue even though the thread in the link is from 2011).

The suggested fix on there is to add the named stdin parameter to the Popen call, which I've done and this seems to fix the problem - tern seems to work correctly with the patch applied.

[marijnh]

Odd, but harmless enough. Merged.

[clausreinke]

@marijnh Actually, connecting to stdin might have advantages:

• data sent to stdin doesn't suffer from http-roundtrip delays (for send-and-forget scenarios like triggering tern_sendBufferIfDirty when leaving an editor buffer)
• if tern server actually starts listening to its stdin, it can also react to its stdin disappearing (that might be a cleaner solution to soft server shutdown, cross-platform)

[marijnh]

That is true. I definitely want to keep the HTTP support around, but it would probably not be hard to make the server take an option that makes it read JSON requests from stdin (and answer on stdout) instead. A downside is that it'll only be able to talk to one client, whereas the current setup aims to be able to reuse a server between several processes. In practice, emacs/sublime users probably do tend to have only one instance of their editor open. I've seen some vim users fire up a whole bunch of editors, I'm not sure how common that pattern is.

A pull request that adds support for this, and adds an option to one or more plugins to make use of it, would be taken seriously.

[clausreinke]

A pull request that adds support for this, and adds an option to one or more plugins to make use of it, would be taken seriously.

Good to know. For now, I've merely used stdin end for (cross-platform) soft exit (#16 (comment)).

Even before this change: if the editor that started tern closes, it shuts down tern, even if other editors are using it; those then time out and start their own tern. This double try pattern has its own disadvantages (#29).

As for vim usage patterns, my experience as a plugin author has been that there are many of them. My own pattern is lots of vim instances, but at most one per project.