Returning the entire help string can be distracting as the minibuffers expands
to try to fit everything on string. The point of eldoc is to help with function
signature.
* Use completing-read instead of ido-completing-read.
Per @seagle0128 and issue #496.
* lisp/ein-notebook.el:
* Wrap all calls to completing-read with ein:completing-read
Use `ein:completing-read' everywhere we need to do completion as it wraps Emacs
completing-read functionality and tries to use sane defaults.
M-x customize-group RET ein
Toggle Ein:Polymode
Avoid trying to emulate jump-to-definition, eldoc, and autocompletion
functionalities that Elpy will always do better.
Fixes#497#482#418
In light of #425 and #456, provide more guidance on curl errors.
Also, clean up eldoc stub. Leveraging elpy's eldoc perfection seems
the only sensible choice, however.
test-compile attempts to egrep "bad" warnings with hardcoded strings.
This is better than nothing, but misses a lot. We are close
to elimiinating this hack in favor of `(setq
byte-compile-error-on-warn t)` to enforce no warnings whatsoever. Until
then, keep adding egrep strings to `test-compile`.
Without `(package-refresh-contents)`, the `make install` won't be able
to download and install dependencies for new users. Remedy this.
Retire files that will never be used.
```
M-x customize-group RET ein-completion
```
Set `Ein:Completion Backend` to `ein:use-none-backend`, Set `State` to
`Save for Future Sessions`.
Also use `featurep` and `with-eval-after-load` to clean up the
subpackage requiring gymnastics.
By covering our ears and ignoring as much as possible. Apparently SyntaxError is
not a subtype of Exception. Also need to send raw strings otherwise unicode
characters will cause fits.
Also added new command, `ein:pytools-reinject` to reinject ein's pytools code.
The name could probably use some work.
Python running on a remote connection doesn't know how to find files on the
local machine, apparently, so we take the route instead of sending the contents
of a temporary buffer loaded with the pytools python code to the running kernel.
I am expecting that `ein:completions--prepare-oinfo' will error out depending on
the type of python object we are looking at, so no need to log an error every
time this happens as it will unnecessarily fill the ein log buffer and generate
lots of annoying notifications in the notebook buffer.
EIN tries to build a cached of pdef's for all potential completion symbols. This
is problematic because not all completion symbols have a pdef and can cause
python to throw exceptions in entertaining and hard to catch ways. We take a
liberal approach and ignore anything that throws an exception when we try to
inspect it.
Eldoc support should also be more robust because of these changes as well.
One line change to fix header not updating after cell execution
(keeps saying "Kernel is busy").
The bug does not manifest when running with `ein:debug` true since
EMACS's display loop updates more frequently with debug messages.
In tracking this bug, noticed eldoc support isn't quite there.
`__import__('ein').print_object_info_for(%s)` appears in
`ein-completer` and `ein-pytools`, and is invalid python syntax
afaict. Took a few steps to make it whole, but incomplete.
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.
Please see the new variable `ein:completion-backend'. Use this variable to
configure which completion backend to use in ein. Currently we support
auto-complete, company-mode, and jedi using auto-complete.
Only six months late. Jupyter changed callback signature for
complete_request, breaking ein's autocomplete code. Missed this for so
long because I am lazy and almost exclusively used jedi for
autocompletion. Ugh.
* Change the call signature of completer callback, to
pass arguments to completer callback.
* Use expand option to suppress auto expansion when
used as dot-complete.
