Use deferred and callbacks instead of `:sync t` for tkf requests which
is known to have issues. Query server attributes once on
notebooklist-open to avoid sequencing issue #176 (but allow Resync).
Under curl backend, a second request for the same "key" as a pending
request will abort the latter, which has resulted in a clobbered
curl-cookie-jar file, so merely warn and don't abort.
Fix#176
Try, but seem to still be mostly failing. Think this is more a personal setup
issue than something in general but this change should, at the very least, not
do any harm.
Really basic support for eldoc, buidling off the oinfo cache code written to
support function annotations for the ein company backend. In theory should also
work the other completion backends, but untested at the moment.
Raise an error if the user does not specify the port or the full URL when
calling functions like `ein:notebooklist-open' and `ein:notebooklist-login'.
It can be debated that ein should assume http over https if the user doesn't
specify, but I currently think it shouldn't. Debate me.
Make `ein:gc-prepare-operation` idempotent and add missing call to
`ein:gc-complete-operation` - without it, each subsequently opened notebook
bumps gc threshold to a higher and higher value, effectively disabling all
garbage collection and seriously degrading overall performance.
Not sure if it is really doing anything, but ein:use-company-jedi-backend is now
a valid setting for ein:completion-backends.
More useful is that connected buffers now use ein's company completeion backend,
so completion should now work across all backends all across ein. Now let's get
something working in org!
Code for getting matches uses deferred and calls to `ein:completer-complete',
avoiding the hacks needed with `ein:completer-finish-completing-company' (names
are shorter too!). Using deferred makes reading the code a bit easier, I think.
EIN will also try to prepare function annotations via the python oinfo object.
Performance is not ideal when the completion candidate list is long, so there is
a new customizable variable `ein:allow-company-annotations' to control this
behavior.
Some functions to find the beginning and ending positions of the python symbol
at point - we might need this if we ever try to implement support for
capf (completion at point function).
This change fixes the issue where notebook being saved is sent to Jupyter with
`Content-Type: application/x-www-form-urlencoded`, because the default value of
this header (`application/json`) gets wiped out in `ein:query-prepare-header`.
The above issue becomes more apparent when notebook contains non-ascii
characters - in such case Jupyter logs a warning: `Invalid x-www-form-urlencoded
body: 'latin-1' codec can't encode characters in position XXX: ordinal not in
range(256)`.
This fixes the `ein:object-at-point' function so it works in `subword-mode'.
Original issue here:
https://github.com/millejoh/emacs-ipython-notebook/issues/313
-------------------------------------------------------------------------
When `subword-mode` is enabled, the `(ein:object-at-point)` function fails after dots. For example, let's say `|` is the cursor and `subword-mode` is enabled:
Calling `(ein:object-at-point)` on this: `tf|` returns `"tf"`. This is correct.
Calling `(ein:object-at-point)` on this: `tf.|` returns `nil`. It should return `"tf."`.
Calling `(ein:object-at-point)` on this: `tf.nn|` returns `nil`. It should return `"tf.nn"`.
One side effect of this is that `company-mode` suggestions stop working after dots in `subword-mode`. For example:
```
import tensorflow as tf
tf.n|
```
Will not provide suggestions from the ein completion engine.
I tried changing the `(ein:object-at-point)` function to return the *symbol* at point, rather than the word, and this fixed the problem. Would this produce any undesirable side effects? If not, I can submit a pull request.
