* Add `jupyter-completion-prefetch-p` which determines if a
prefetch should be performed.
* Remove `jupyter-completion-last-prefix`. Store all of the
necessary information in `jupyter-completion-cache`.
* Remove the invisible character inserted along with the
continuation prompt as it is really unneeded.
* Make the inserted space two characters wide. For some
reason this is needed, otherwise the continuation prompt
will be one character short when starting up a REPL from
the byte compiled functions. Curiously when I evaluate
`jupyter-repl-insert-prompt` in the current Emacs
session, the prompt looks fine afterwards.
Insert the HTML directly into the REPL buffer and use
`shr-render-region`. This avoids copying the HTML to a
temporary buffer first and extracting the rendered HTML to
place in the REPL buffer.
The python kernel includes every attribute up to the parent
object, we need to split on the dots to only have the last
attribute or method since that is what the bounds are in
the completion mechanism.
* Add a context rewriter `jupyter-repl-mode` which checks
that the variable `jupyter-repl-lang-mode` is of the
right mode.
* Remove the check for `jupyter-repl-mode` since major
modes do not have a mode variable.
* Add `jupyter-repl-after-init` to `jupyter-repl-mode-hook`
* Move the special case of syntax highlighting for javascript kernels that
use `js2-mode` to its own `jupyter-repl-after-init`
specialized method.
`point-max` is now considered the end of a cell but if the
end of a cell is `point-max`, then it is by definition
un-finalized. Also return t if the current line is not a
cell line since those parts of the buffer that are not
cells are finalized.
* Define the `jupyter-lang` method context specializer that
specializes against the kernel language of
`jupyter-current-client`
* Remove the kernel support API
* Replace the kernel support API with methods that can be
specialized using the `jupyter-lang` context specializer.
* Rename `jupyter-code-context-at-point` to `jupyter-code-context`
* Use `cl-defmethod` and specializers to handle the
different kinds of contexts
* Move the newly defined code context methods to their
appropriate locations
* Define new method `jupyter-kernel-info` which takes care
of caching the result of a kernel info request. All
access of the kernel info plist should happen through
this method.
* Do not return the kernel info plist in
`jupyter-start-new-kernel`, callers should access the
kernel info through `jupyter-kernel-info`
