Don't think we were handling https:// url's correctly.
Also some code cleanup in ein-connect; fix longstanding bug in ein:load-files,
and tweak default timeout for starting a jupyter session from within emacs.
Trying to increase reliability of starting a juptyer server from Emacs. Deferred
is cool, but a pain to understand for this old brain.
Fix some typos in ein-ob and be smarter selecting completion backend when
connecting a python buffer to a jupyter notebook.
Instead of just enabling auto complete why not just connect to the notebook ala
`ein:connect-to-notebook`?
Update dependencies documented in README.rst
Force version check when starting the jupyter server - ein seems to be easily
confused in this regard.
Will try to use ein completion backend configured by user when editing ein
source blocks in org.
Also slightly more robust inspecting in ein_inspector.py
Order entries in notebooklist by file type (i.e. file extension). Add function
'ein:jupyter-server-stop to 'kill-emacs-hook.
Fixed link in documentation.
Add configurable timeout (see `ein:jupyter-server-run-timeout`) that will
hopefully abort calls to `ein:jupyter-server-run` that hang; this is to help
with issues like those reported in #176.
Also update documentation, dependencies in preparation for 0.13.0 release.
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.
When running against jupyterhub master (which will someday be v0.8) can know log
in and make calls to the contents api.
Everything is working except for opening websocket connections.
`ein:jupyterhub-connect' is now interactive and will query for url, user, and
password before trying to authenticate in Jupyterhub and start a server for the
user.
We can do all of these through the function `ein:jupyterhub-connect'. Everything
works great until we actually try to access the running notebook server at which
point the hub redirects us to the login page. I've bumped to the mailing list,
we will see if anyone there can help.
`ein:jupyterhub-connect' will take a url for the jupyterhub server, a user, and
a password and then get and store the authorization token for that user.
Big things on the way!
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.
It seems there are enough people out there still on Emacs 24 to warrant undoing
some of my recent moves away from eieio to cl-generic. For the near future I
will try to keep any changes that are incompatible with Emacs 24 to a
development branch. There is still probably plenty of opportunity to make the
code more future-proof for an eventual move away from eieio (I'm looking at you
oref and sref...)
Images weren't being save to json in the way they should have. Mostly had to do
with how the attirbutes were being ordered. This is still, unfortunately, a
nasty bit code but it still seems to work.
It seems that in some instances EIN is failing to install on emacs installations
that do not have auto-complete, so for the moment I am making auto-complete a
required package.
If this causes you a problem please log an issue on the project issues page
(https://github.com/millejoh/emacs-ipython-notebook/issues) and let me know
what is happening on your system.
I swear I though I was on another branch when I commited the dynamic javascript
stuff but, well, nothing to be done now I suppose.
With very basic support for evaluating javascript code now available I am adding
the skewer-mode dependcy as I should have done originally.
Note that yes, one can execute javascript in code blocks with the %%javascript
magic, but don't expect the really cools things like widgets or interactive
visualizations (ala %matplotlib notebook) to suddenly start working.
There is a lot more work to be done here, and possible it will never be possible
to have interactive widgets in the emacs notebook buffer, but I am hopeful that
one day we will at least be able to pop-up a browser window with a widget and
have it "talk" to the emacs notebook buffer.
Starting ipython/jupyter notebook servers from EIN should now be more robust.
Will try to detect correct url/port whether or not token authentication is
enabled, and if not will try to alert the user.
Also using `start-process` to run the notebook server - I think this will allow
compatibility with emacs24.
Do a better job of selecting the major mode for cell edit buffers. Will try to
detect if there is a cell magic, like %%html or %%latex, and set an appropriate
major mode.
If it cannot determine what the major mode should be and the cell type is raw,
the major mode will default to whatever is set in the user customizable variable
`ein:raw-cell-default-edit-mode', which by default is set to `'LaTeX-mode'.
