The standard way to avoid this problem is to use autoload instead of require.
This way ESS is not required to compile and run EIN and it is only loaded if the user actually uses it.
```
"http://localhost:8888"
"http://localhost:8888/"
"http://127.0.0.1:8888"
"http://127.0.0.1:8888/"
"8888"
8888
```
Ideally these should converge to the same thing. Since many hash
tables are keyed off `url-or-port`, forgetting to
normalize `url-or-port` with `ein:url` leads to missed cache hits and
general malaise. So we try to do that.
Address a FIXME: apply callbacks to `ein:notebook-list-login-and-open`.
Removed py3.5 from travis build matrix to reduce developer strain.
Not sure if it is really doing anything, but ein:use-company-jedi-backend is now
a valid setting for ein:completion-backends.
More useful is that connected buffers now use ein's company completeion backend,
so completion should now work across all backends all across ein. Now let's get
something working in org!
Code for getting matches uses deferred and calls to `ein:completer-complete',
avoiding the hacks needed with `ein:completer-finish-completing-company' (names
are shorter too!). Using deferred makes reading the code a bit easier, I think.
EIN will also try to prepare function annotations via the python oinfo object.
Performance is not ideal when the completion candidate list is long, so there is
a new customizable variable `ein:allow-company-annotations' to control this
behavior.
Also update loaddefs and add an additional option for ein's completion backend:
`ein:use-custom-backend'. When enabled EIN will not automatically use any
autocompletion mechanism, instead leaving the configuration details to the user.
Please see the new variable `ein:completion-backend'. Use this variable to
configure which completion backend to use in ein. Currently we support
auto-complete, company-mode, and jedi using auto-complete.
