Also make `jupyter-wait-until-startup` private by renaming to
`jupyter--wait-until-startup`. Startup messages are only sent once at kernel
startup, since the only way to start a kernel is through a
`jupyter-kernel-manager` it makes more sense to only allow a kernel manager to
wait for a startup message.
The `jupyter-<channel>-message-hook` variables (where <channel> is one of
`shell`, `stdin`, or `iopub`) are run as the first step when calling the
`jupyter-handle-message` methods for a channel. The hooks take a single
argument, the message which was received on the channel.
Adding a function to `jupyter-iopub-message-hook` in combination with setting
`jupyter-include-other-output` to t eliminate the need for
`jupyter-missing-request` which was a way to add callbacks for messages which
did not have a parent header. Namely the status: starting message.
For each message received in response to a request, record the
`last-message-time` of any received messages for a request. When a request's
`idle-received-p` field is non-nil and the `last-message-time` is larger than
some number of seconds, remove the request from the request table.
- Use `ignore-errors` around `jupyter-connection` slots since they can be
inherited by the `parent-instance`. Note that checking if the slot is
available does not also check if the slots availability in the
`parent-instance`
- Set `addr` where it is used, namely in `cl-loop`
This is a function which should be called on a `jupyter-kernel-client` and it
returns a request object which can be used to add callbacks to messages that
have no parent message such as the status: startup message sent be a kernel.
Break it into several macros which perform various subtasks like processing a
command received from the parent emacs process and collecting messages into a
sorted list based on `jupyter-message-time`
This way when creating kernel clients with `jupyter-kernel-manager`, we can set
the `parent-instance` of the newly created client to the manager thereby
inheriting the `jupyter-session` from the kernel manager.
Also have `jupyter-channel` objects inherit from a `jupyter-connection` so that
we can define `jupyter-send` and `jupyter-recv` methods for channels in the future.
- 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.
- `jupyter-client.el` only contains client related code
- `jupyter-kernel-manager` related code is placed in `jupyter-kernel-manager.el`
- Socket creating functions and generating connection info plist function are
placed in `jupyter-connection.el`. This also contains the
`jupyter-connection` class.
- Kernelspec related functions are placed in `jupyter-kernelspec.el`
- Move general utility functions and variables requires necessary for `jupyter`
into `jupyter-base.el`. This also contains the `jupyter-session` and
`jupyter-request` struct definitions.
