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`
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.
