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.
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?
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.
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.
