`(byte-compile #'cons)` will return `t` which is not a function.
Passing in the `subr` to `byte-compile` will just return the `subr` so
everything works out OK. This is an attempt at fixing issues like
nnicandro/emacs-zmq#32.
Previously it was hard to step through the code whenever messages were
coming in live from a kernel due to the asynchronous nature of
handling process output in Emacs.
`default-directory` is already set according to :dir when executing a
source block. This prevents `org-babel-expand-body:jupyter` from
attempting to re-expand the value of the :dir header argument.
See #302.
* ob-jupyter.el
(org-babel-jupyter-initiate-session-by-key): Get rid of unnecessary
variable.
(org-babel-jupyter-cleanup-file-links): result-pos -> pos, link-path
-> path, link-dir -> dir. Add resource-dir variable to avoid
calculating the same thing in a loop.
(org-babel-execute:jupyter): kernel-lang -> lang
There was an implementation of `jupyter-start-channels` for a
`jupyter-kernel-process-manager` due to the manager being able to send messages
to the kernel via a kernel's control channel. The channel currently serves as
an implementation detail of the manager class, don't allow its status to be
controlled outside of the manager class by removing the implementation.
In addition, remove the `jupyter-stop-channels` implementation since
it is no longer needed.
* jupyter-kernel-manager.el (jupyter-start-kernel): Remove call to
`jupyter-start-channels` on MANAGER. This should not have been done in the
first place since only `jupyter-kernel-process-manager` implemented that
method, as explained. Also remove the `jupyter-kernel-alive-p` call, this is
already done in an :around method of `jupyter-kernel-alive-p`, see
`jupyter-kernel-lifetime`.
* jupyter-kernel-process-manager.el
(jupyter-start-channels, jupyter-stop-channels)
[jupyter-kernel-process-manager]: Remove. For `jupyter-stop-channels`, expand
body at call site.
(jupyter-start-kernel) [jupyter-kernel-process-manager]: Start the control
channel as a final step.
(jupyter-shutdown-kernel, jupyter-interrupt-kernel): Remove
`jupyter-start-channels` call.
Replace it with a handler function passed to `jupyter-ioloop-start`.
* jupyter-ioloop-comm.el: Do it.
* jupyter-channel-ioloop-comm.el: Do it.
* jupyter-channel-ioloop-comm.el: Do it.
* jupyter-ioloop.el: Do it. Update comments and doc.
(jupyter-ioloop--delete-process): Remove. It was used to perform
cleanup when the object used for dispatching to a handler method was
garbage collected. Since we no longer rely on having an object for
dispatching, preferring just a function to call, its not needed.
(jupyter-ioloop--make-filter): Fall back to calling handler function
instead of `jupyter-ioloop-handler`. Only handle ioloop start/stop
events internally. This means we can remove the check for those in
`jupyter-ioloop-comm`.
* test/jupyter-test.el: Update tests to take into account above
changes.
This in preparation for removing the `jupyter-ioloop-handler` method
altogether.
* jupyter-ioloop-comm.el
(jupyter-channel-ioloop--set-session): Promote to public function.
(jupyter-ioloop-start): Remove `jupyter-session` based
implementation. Preferring sub-classes to call
`jupyter-channel-ioloop-set-session`.
* jupyter-channel-ioloop-comm.el
(jupyter-comm-initialize): Use the newly public function.
We would still like a message indicating that a kernel process starts on
Windows.
* jupyter-kernel-process-manager.el
(jupyter-start-kernel) [jupyter-spec-kernel]: Do it.
* jupyter-base.el (jupyter-read-connection): New function.
* jupyter-kernel-process-manager.el
(jupyter-start-kernel) [jupyter-command-kernel]: Use it.
`jupyter-org-closest-jupyter-language` falls back to asking a user for a
kernel, when it does so `point` is at the beginning of the buffer. Make sure
`point` is at the location where the user last left it.
* jupyter-org-extensions.el (jupyter-org-closest-jupyter-language): Do it.
* ob-jupyter.el
(org-babel-jupyter-server-session)
(org-babel-jupyter-parse-session): Convert to method and re-implement
with :extra methods.
* test/jupyter-server-test.el
(org-babel-jupyter-server-session): New test.
* test/jupyter-test.el
(org-babel-jupyter-parse-session): Move test of server based sessions
to the new test.
There is no need to do so since
`jupyter-repl-font-lock-fontify-region` already takes care of
narrowing to cell bounds and `font-lock-syntactic-face-function` is
called during the fontification process of the narrowed cell.
The boundaries of cell text are already considered by
`jupyter-repl-map-cells` (called during fontification) so there is no
need to, in addition, have the `font-lock-multiline` property (see the
documentation of `font-lock-extend-region-functions` for what that
property is meant to do).
With regards to the comment, since the buffer is narrowed to the cell
text during fontification, syntactic fontification is contained within
the cell.
There is no need to have an extra function call and they were not used
anywhere else.
* jupyter-zmq-channel.el
(jupyter-send, jupyter-recv) [jupyter-session]: Remove. Update all
callers.
