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.
This needs to be changed. `company-grab-symbol` will only grab 'bar' when
cursor is at | in the following:
foo.bar|
We would like it to grab the whole 'foo.bar' and let the kernel figure out what
to do. Similarly for other operators like '->'. The problem that needs to be
fixed is to properly replace just the 'bar' part if 'foo.bar' is the prefix. I
believe the `match` command of a company backend will be of use.
- 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.
This `jupyter-kernel-client` subclass generates the following messages when a
message is sent on one of its channels:
status: busy
<msg>
status: idle
Where the content field of <msg> will be the same plist as the sent message and
the type of <msg> is the reply type of the request. No actual communication is
done with a kernel, the messages are just placed on each channels recv-queue
- `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.
Specifically the REPL is always initialized with a new prompt due to
`jupyter-repl-update-execution-counter` being called as the final step in REPL
initialization. This means that there is no need to catch a
`beginning-of-buffer` error in `jupyter-repl-ret`.
Also remove the need for the `code` variable, just use `jupyter-repl-cell-code`
directly in the `jupyter-is-complete-request`.
This avoids problems with a reply message and a status idle message being
received at identical times for a request. Two messages can be received at the
same time when the fractional seconds resolution of the time stamps received
from the kernel are not high enough. If the iopub channel had a higher priority
it would mean that the idle message would be received before the reply when
they have identical time stamps. Since request objects are removed from the
client when an idle message is received this would prevent any reply callbacks
from running.
To combat this problem, prioritize the shell messages over any other type of
message.
