* 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`
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.
Since IDs of requests are generated in the parent Emacs process, there is no
need to pass back the ID of a request from the child process that send
messages.
- Add the method `jupyter-generate-request` to allow subclasses to initialize
their own request objects with extra fields in addition to those of
`jupyter-request`.
- Add the method `jupyter-drop-request` to allow subclasses to do any cleanup
once a request is complete.
- Add missing namespace to sha256 function
- Any function defined should have a `jupyter-` prefix
- Remove `cl-lib` dependency in `jupyter-messages.el`
- Include `subr-x` in `jupyter-base.el`
- Use `tramp-file-name-user` instead of `tramp-file-name-real-user` since the
latter is missing in Emacs 26
- Allow specifying a msg-id before a call to `jupyter-send`
- This avoid sending a message to the browser displaying the widgets on every
message send to the kernel. The previous implementation generated a new ID
without allowing the caller to pass one in.
- Simplify message polling by sending received messages from the kernel to the
parent Emacs process at the moment of arrival.
To make up for this:
- Move the functions defined in `jupyter-connection.el` to `jupyter-base.el`
- Add a `session` field to the `jupyter-kernel-manager` and `jupyter-channel`
classes
- Add a `kernel-info` field to the `jupyter-repl-client`
- Add a `conn-info` field to a `jupyter-session`
- Add a `session` field to `jupyter-kernel-client`
Messages were queued by the messages sent timestamp in the message header as
well as based on the channel the message was received on because there is no
guarantee on the order of the received messages. This matters because a request
is dropped from a client's request table when an idle message is received, but
this idle message is not guaranteed to be the last message received for a
request, for example a reply message may come after the idle message has been
received.
Now if a request has received an idle message already, instead of
dropping it immediately, drop it only when the last received message time for
the request is longer than a few seconds.
Handler methods are only run on a successful request. If an error occurs during
execution an error message is emitted on the IOPub channel, this is where
errors are handled. Or they can be captured in the reply messages through
callbacks.
`jupyter-inhibit-handlers` can now be a list of message types. If a message is
received and has one of these message types, then the client handler
corresponding to that message type is prevented from running.
Setup the necessary hooks before starting the kernel so that we can ensure that
the startup message is caught.
A short delay is also added whenever we start a channel. This was necessary for
the client to catch the startup message of a python kernel.
