* 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`.
* 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`
If Emacs crashes while a channel subprocess is still alive, the subprocess is
not cleaned up properly. Fix this by creating a file lock in the parent Emacs
process, then ensure that the file lock exists in the channel subprocess. If it
doesn't exist anymore, the channel subprocess will exit.
* Set the lazy highlight limit to only look at the current cell
* Simplify `jupyter-repl-history-next` and `jupyter-repl-history-previous`
* Properly restore isearch state when searching through history
* Add tests for REPL history navigation
* Handle the case of no time specification by defaulting to midnight when
decoding time
* Properly handle fractions in `jupyter--decode-time`
* Implement `jupyter--encode-time`
* Consider a time object to be a length 4 list of integers and encode the
object using `jupyter--encode-time` when encoding in `jupyter--encode`
* Add tests for time decoding/encoding
- Rename `jupyter-received-message-types` to `jupyter-message-types` and add
message types for requests as well. Also change the keys to keywords instead
of symbols. Using plists with keywords is in line with `jupyter-messages` and
the arguments of the jupyter request functions.
- Rename `jupyter-request-run-callbacks` to `jupyter--run-callbacks`. This is
more of an internal function so mark it as such.
- Change the order of the first two arguments in `jupyter-add-callback` and
`jupyter-wait-until`. In both cases you are adding a callback to a request or
waiting for some condition to be satisfied on the request not on the message
type. This is also the reason why `jupyter-wait-until-received` keeps the
message type as the first argument. We are waiting until a message of a
certain type is received for a request, but the more important object in this
case is the message type.
- Update other files to take into account these changes.
This `jupyter-kernel-client` subclass generates the following messages when a
message is sent on one of its channels:
status: busy
<msg>
status: idle
Where the content field of <msg> will be the same plist as the sent message and
the type of <msg> is the reply type of the request. No actual communication is
done with a kernel, the messages are just placed on each channels recv-queue
