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?
Update help message in travis as well. Get rid of case-fold check for the
moment. It works fine locally, but travis can't seem to wrap its head around the
test.
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.
Hard to reproduce exactly what is happening, but try to work around the
possibility of a company completion popup appearing in the buffer or minibuffer.
We have to be careful about setting it globally because that seems to be causing
some conflicts, better to set it at the buffer level when we are opening a
notebook otherwise ein:company-backend may not be activated.
- Make sure we only cache actual python objects.
- Do better when we are completing in the middle of an object.
To that end is the new function `ein:object-prefix-at-point' that returns the
prefix for the dotty.thing.at.point. See the function documentation for more
info.
Generally, ob-lang modules cannot require org, else it gets into
infinite require loop.
This begs the question whether ob-ein is really used by anyone.
