The goal of this method is to act as a single entry point for insertion of
kernel results in any context. One would simply add another method to handle a
specific context.
* jupyter-base.el (jupyter-mime-types):
(jupyter-nongraphic-mime-types): New variables that give mime-types that can be
handled.
(jupyter-insert): New method for dispatching to code that inserts mimetype
representations in the current buffer.
* jupyter-mime.el: New file.
(jupyter-display-ids):
(jupyter-handle-control-codes):
(jupyter-fontify-buffers):
(jupyter-get-fontify-buffer):
(jupyter-fixup-font-lock-properties):
(jupyter-add-font-lock-properties):
(jupyter-fontify-according-to-mode):
(jupyter-insert-html):
(jupyter-markdown-mouse-map):
(juputer-markdown-follow-link-at-point):
(jupyter-insert-markdown):
(jupyter-insert-latex):
(jupyter-insert-ansi-coded-text): Moved from jupyter-repl.el, replaced
`jupyter-repl-` prefix with `jupyter-`.
(jupyter--shr-put-image): Ditto. Also add `shr-` prefix.
(jupyter--delete-javascript-tags): Ditto. Also mark as private functions.
(jupyter-insert-image): Ditto. Also mark as a public function.
(jupyter-insert): (DISPLAY-ID ...) Moved from jupyter-repl.el. Was
`jupyter-repl-insert-data-with-id`.
(jupyter-with-control-code-handling):
(jupyter-markdown-follow-link): Moved from jupyter-repl.el
(jupyter-insert): Implement methods to do the work previously done by
`jupyter-repl-insert-data`.
* jupyter-repl.el (jupyter-repl-graphic-mimetypes): Moved to jupyter-base.el,
inverted and renamed to `jupyter-nongraphic-mime-types`.
(jupyter-repl-graphic-data-p): Remove unused function.
(jupyter-repl-insert-data): Remove, replace calls with `jupyter-insert`.
(jupyter-repl-add-font-lock-properties):
(jupyter-repl-fixup-font-lock-properties):
(jupyter-repl-get-fontify-buffer):
(jupyter-repl-fontify-according-to-mode):
(jupyter-repl-delete-javascript-tags):
(jupyter-repl-put-image):
(jupyter-repl-insert-html):
(jupyter-repl-markdown-mouse-map):
(jupyter-repl-markdown-follow-link-at-point):
(jupyter-repl-insert-markdown):
(jupyter-repl-insert-latex):
(jupyter-repl--insert-image): Moved to jupyter-mime.el, which see.
(jupyter-repl-insert-data-with-id): Ditto. Changed to a `jupyter-insert` method
dispatched on a string argument.
(jupyter-repl-insert-ansi-coded-text): Ditto. Replace calls with
`jupyter-insert-ansi-coded-text`.
(jupyter-with-control-code-handling):
(jupyter-markdown-follow-link): Moved to jupyter-mime.el.
* jupyter-org-client.el (jupyter-handle-error): Replace
`jupyter-repl-insert-ansi-coded-text` with `jupyter-insert-ansi-coded-text`.
* jupyter-tests.el (jupyter-insert): Add tests for `jupyter-insert`
* jupyter-tests.el (jupyter-with-echo-client): Call `jupyter-finalize`.
(jupyter-channels): Remove references to asynchronous
channels and old channel slots of a `jupyter-kernel-client`. Replace with
using the new `channels` slot of a `jupyter-kernel-client`.
(jupyter-messages): Test message signing and decoding.
(jupyter-ioloop-test-handler-called): New variable for tests.
(jupyter-ioloop-handler): New method for tests.
(jupyter-ioloop-lifetime):
(jupyter-ioloop-setup):
(jupyter-ioloop-teardown):
(jupyter-ioloop-add-event):
(jupyter-channel-ioloop-send-event):
(jupyter-channel-ioloop-start-channel-event):
(jupyter-channel-ioloop-stop-channel-event): New tests.
(jupyter-channels): Split into `jupyter-sync-channel`, `jupyter-hb-channel`.
(jupyter-test-conn-info-plist): New function for tests.
(jupyter-client): Split into `jupyter-initialize-connection`,
`jupyter-inhibited-handlers`. Remove `jupyter-finalizer` test.
(jupyter-client-channels): New test.
* Add `jupyter-completion-prefetch-p` which determines if a
prefetch should be performed.
* Remove `jupyter-completion-last-prefix`. Store all of the
necessary information in `jupyter-completion-cache`.
* Define new method `jupyter-kernel-info` which takes care
of caching the result of a kernel info request. All
access of the kernel info plist should happen through
this method.
* Do not return the kernel info plist in
`jupyter-start-new-kernel`, callers should access the
kernel info through `jupyter-kernel-info`
If Emacs crashes while a channel subprocess is still alive, the subprocess is
not cleaned up properly. Fix this by creating a file lock in the parent Emacs
process, then ensure that the file lock exists in the channel subprocess. If it
doesn't exist anymore, the channel subprocess will exit.
* Set the lazy highlight limit to only look at the current cell
* Simplify `jupyter-repl-history-next` and `jupyter-repl-history-previous`
* Properly restore isearch state when searching through history
* Add tests for REPL history navigation
* Handle the case of no time specification by defaulting to midnight when
decoding time
* Properly handle fractions in `jupyter--decode-time`
* Implement `jupyter--encode-time`
* Consider a time object to be a length 4 list of integers and encode the
object using `jupyter--encode-time` when encoding in `jupyter--encode`
* Add tests for time decoding/encoding
- 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