- Introduce `run-handlers-p` for `jupyter-request` objects. When this field is
non-nil, a clients `jupyter-handle-message` method will pass the message to
the channels `jupyter-handle-message` after running any callbacks. Otherwise
the channel handlers will not be run. This gives a way to suppress the
channel handlers for a request.
- Also remove the use of `jupyter-callback` since `jupyter-handle-message` for
a client just removes requests when an idle message is received. The callback
object was used to check if a callback actually ran.
This method dispatches to the appropriate message handlers based on the type of
channel passed to `jupyter-handle-message`. This method is also defined for a
`jupyter-kernel-client` in which case any callbacks for a message will be run
and then the message passed to the channel handlers.
- Only modify/access the `:jupyter-pending-requests' property of the ioloop
subprocess through `jupyter--ioloop-pop-request' and
`jupyter--ioloop-push-request'
- Push a message into a channels receive queue using
`jupyter-channel-push-message'
Where `jupyter-request-*` are the `jupyter-kernel-client` request methods. This
required the underlying messages request message functions to be renamed to
`jupyter-message-*-request` from `jupyter-*-request`.
Allow for visually displaying a cell as busy when submitting the cell's code
and only remove the busy status when the cell receives its execute reply. This
allows for queuing of code cells instead of having to wait for a code cell to
complete.
- Add a text property `jupyter-request` to the start of an input cell which
gets filled with the `jupyter-request` object returned by the
`jupyter-request-execute` method. This way REPL cells can be queued behind
long running calculations and their proper location found when the kernel
sends back output or results for the request.
