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