Try to sanely decode text on windows sytems to avoid getting a buffer full of ^M
EOL symbols when opening files through ein's notebooklist buffer.
This doesn't appear to be necessary on Unix systems, and by extension I am going
to assume it is also the same on Mac OS X.
ein company backend now dutifully looks for the file and line where an object is
defined when company so asks it. When ein fails in its duty it fails silently
and I am not sure yet if that is the correct behavior. For now it will stand,
until I think of something better.
ein company backend will now show results of inspect_request in a company
documentation buffer when company requests documentation via the doc-buffer
command.
The backend was working properly only when completing at the beginning of the
lines. For example, completing `import IPython.` would end up replacing the
import and moving IPython to the beginning of the line. EIN's company backend no
longer does this.
EIN now lists other file types in notebooklist buffer and will allow user to
open those files for editing. The new buffer will get the right major-mode most
of the time, but has a hard time getting the line coding right on Windows
platform.
There is now a company mode backend for ein. It generates completions by sending
complete_request to the running kernel so for the moment no jedi integration.
Configuring is maybe non-obvious - user should at minimum set
`ein:use-auto-complete` and `ein:use-auto-complete-superpack` to nil. Adding a
`(require 'ein-company)` probably should be done somewhere in the user's init
file. This could all be done better so I will attempt to address in later
commits.
Silly typo in ein-kernel.el. Querying kernelspecs is slightly more efficient,
caching results when url is a string or port (previously just cached results for
ports).
Per popular request, publishing what I have so far for jupyterhub support, which
is not much. But it may server as a starting point for someone smarter than I.
This reduces some of the complexity in testein.py, but unfortunately running
tests is still unreliable. Running batchwise tests don't work at all in Windows,
and running from inside emacs tests often need to be run multiple times before
they pass.
The worst offender is the delete notebook test, which will pass on usually only
1 out of 3 tries.
Testing seems to have revealed a couple bugs, so win??
There may be situations when a jupyter server restarts at a new url/port while a
notebook is open. This function allows the user to specify the new url/port and
continue using the notebook (or at the very least, save any changes made while
the server was down and rebooting). EIN will helpfully try to restart the kernel
once the url is changed. Jupyter may complain about session not being found, but
it does not seem to affect the running kernel.
Make even more unique edit-cell buffer names. Check that an edit-cell-buffer
does not already exits before creating one.
Also try to be even more aggressive in limiting output in backtraces when
debugging ein.
Modify ein:get-kernel so it can retrieve the kernel from the local
worksheet variable in edit-cell-mode. This is done so that functions
such as ein:completer-complete and tooltips / inline help are
availeble to be bound by the user.
Check that `filename` actually exists before jumping to it.
Without this patch M-. on an arbitrary word ZZZ creates two empty buffers,
one named "None" and the other named (yes, this is the actual buffer name):
"code.py:456: UserWarning: Argument given (ZZZ) can't be found as a variable or as a filename."
Login and notebooklist requests have a tendency to fail with the curl request
backend when there is no cookie jar file. Request will create the cookiejar, but
apparently with the asynchronous nature of ein this happens too slowly causing
content REST queries to fail. My tactic here is to repeat the call once, and
only once when a failure is detected. It is a difficult problem to reliably
create so I'm not sure if this is a good fix or not. Time will tell.
