- Distinguish between an asynchronous channel and a synchronous one
- `jupyter-async-channel` :: Messages are sent and received through an ioloop
subprocess that the channel has access to. The
subprocess uses the `jupyter-sync-channel` for
sending and receiving messages.
- `jupyter-sync-channel` :: Messages are sent and received through a
`zmq-socket` in the current Emacs session.
- Define `jupyter-send` and `jupyter-recv` methods for channels.
- Update `jupyter-kernel-client` and ioloop interfaces to take into account
changes with channels.
Since client local variables are associated with a buffer a buffer needs to be
present when the client is first initialized. This buffer is also used as the
process buffer of the ioloop subprocess.
Do this because the process buffer is current in the filter, see
`zmq-start-process`. Since we store buffer local values of variables (like
message hooks) there we
would like to have access to them in the handlers.
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`
