Multilang support for c, c++11, c++14, and c++17. Org babel source blocks are
also support.
Dropping (for a moment) testing against python27 on travis.
Otherwise we will try to execute python code in a non-python environment. This
doesn't break anythng, but can fill the log with many, many errors.
In the future might be interesting to add language-dependent methods of
generating object information.
* Stage 1: Go to python 3 for OS X.
* Resolving prompt-toolkit conflict.
Somebody (not sure who) wants prompt-toolkit version to be between 1.04 and
2.00, but jupyter-console needs at least v2.00. First try - use a higher IPython
version.
* Try to force prompt-toolkit version on OS X.
Trying fix suggested in issue #370 (https://github.com/jupyter/jupyter/issues/370).
* Wrong operator for pip install prompt-toolkit.
* Play with IPython version, remove potentially redundant ipykernel install.
* Now we can't find jupyter on OS X.
The install looks good, though.
* Python 3.7.6 is still a release candidate. Sigh.
* Get serious about setting the PATH with pyenv.
* Is the shell set up for pyenv virtualenv?
* ELPA and emacs 25 are not getting along.
* Restarting the shell is a bad idea.
* I suspect the issue is with package gpg signatures.
* Try emacs 26.3 for OS X build.
Unsure what those situations are, but when it happens it breakes ein's undo
facility. Calling `length' on a dotted list will generate wrong-argument-type
errors. To help soften the consequences of those situations we call `safe-length'
instead of `length'.
Modifying ein:%which-cell% when the cell hasn't changed can lead to an obscure
error.
Also, probably unnecessary, but make sure buffer-undo-list is not t (which is a
valid value for this variable) when unshifting.
Notebook performance would noticeably suffer when doing completions in large
namespaces (I'm looking at you pandas) because it could result in many (100's)
of individual calls to `__ein_print_object_info_for'. This was very inefficient,
so now what the code does is make a single python call to generate oinfo results
for a list of completion candidates. Performance seems much improved, but only
time will tell if this is just my imagination or not.
You still need to import matplotlib first, but after doing that if you call
`ein:pytools-matplotlib-api-correction' then ein will try to automatically
adjust the figure dpi to something appropriate for the current display. Setting
up the appropriate hooks to get all this to happen automatically upon opening a
notebook is left as an exercise to the user.
* Better consistency with kernel connections in anonymous ob-ein blocks.
And some tests to try to prove this is the case.
* Make sure company-mode is enabled.
* Undo cursor shifts.
* Company mode still not catching.
* Travis unhappy with undo and anonymous completion.
Tests work locally, but fail on travis. Let's play around a bit.
* Revert undo position jiggers.
I think the issue is character or line ending encoding in WSL (i.e. Windows) and
a "normal" Linux setup.
The modern Jupyter messaging spec (> 5.0) simplified `complete_request` to allow
sending blocks of text as completion context. EIN now takes advantage of this by
sending the entire contents of the worksheet cell, when in a notebook buffer,
or, when in a non-notebook buffer, the entire contents of the buffer. This
allows backends like jedi to do better context-sensitive completion without
having to execute code. In general this should improve completion behavior,
though may result in an initial performance hit when working in large buffers
while EIN builds the oinfo cache. Note that oinfo (i.e., function call
signatures) will not be available until code in the buffer/cell is executed.
* ein-ac: Fail silently for unexpected ein:completion-backend values.
Fixes#608, though we really need a test cases for completion in polymode.
* Only define ein ac-sources when the user explicitly sets the backend.
* Test case for issue #608.
* Only test jedi completion when testing polymode.
* Add epc dependency for emacs-jedi.
* Flanging up with travis is always a challenge.
* Forgot to update the scenario.
* Give jedi time to install.
* Add virtualenv to travis OS X build.
Also add some addition TOX environments for future testing cases.
* OS X travis is failing - is it a timeout issue?
