Replace `defun*' with `cl-defun', `loop' with `cl-loop',
`case' with `cl-case', `assert' with `cl-assert',
`destructuring-bind' with `cl-destructuring-bind',
`multiple-value-bind' with `cl-multiple-value-bind',
`equalp` with `cl-equalp`, `defstruct' with `cl-defstruct`
&c &c &c
Use lexical-binding instead of lexical-let.
Add declarations and defvar to avoid breakage.
As emacs users we prefer and have the luxury of fuzzy file navigation
via ido and projectile. From a notebook or notebooklist buffer, the commands
`C-c C-f` ein:file-open
`C-c C-o` ein:notebook-open
offer an ido alternative to point and click navigation.
To populate the ido lists, retrieving the content hierarchy is on by
default. Two custom variables determine how wide and deep the content query
probes (currently at 2 levels deep and 6 directories wide). Set both
to zero to turn off.
tkf half finished code to quickly go from local file buffers to notebook
mode via `C-c C-z` or `C-c C-o`. This is now possible. EIN will
start the server from a suitable parent directory of the visited file.
Enable ido completion for `notebooklist-login`.
Remove the albatross `ein-loaddefs.el` in favor of more standard
`ein-autoloads.el` that is not git tracked.
Convenience `make install` from git source (local alternative to
melpa).
Merge the login and open commands (open aliased to login). Add login
tests described in #352.
Attempt to improve user experience by synchronously executing
`ein:jupyter-server-start`. `ein:dev-prefer-deferred` custom variable
allows easy switch to compare sychronous versus old asynchronous behavior.
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!
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.
