A BEGIN_SRC block can specify which mime type to display by enabling the
user to manually set the priority order of mime types.
e.g.: In the following, :text/plain will be used before considering :text/html
#+BEGIN_SRC jupyter-python :display plain html
`jupyter-org-with-src-block-client` is used in the `completion-at-point`
interface and `with-current-buffer` is slow so there should be a slight speed
up here.
Check for a latex fragment org-element instead of skipping over words. The
previous behavior would cause a large slow down if the results contained a
large amount of text.
This replaces the `jupyter-repl--handle-payload` function and allows payloads
to be handled in other contexts than the REPL, for example inserting a new
source block when receiving a set_next_input payload for the `org-mode` client.
This is a minor mode, enabled in `org-mode` buffers by default, that provides
completion and Jupyter specific keybindings in Jupyter code blocks.
Whenever `point` is inside a Jupyter code block, some of the keybindings
available in `jupyter-repl-interaction-mode` are available directly in the
`org-mode` buffer. Completion is also available from the `org-mode` buffer.
Any `org-element` that has a type in `org-element-all-objects` does not have a
newline appended to it when converting to a string representation. This commit
ensures that a newline is added wherever necessary for such elements.
Fixes#8
In particular, file link objects. When an object (in the sense of the
`org-element` API) is inserted by `org-element-interpret-data` it does not
insert a newline since objects are entities that can appear inline with a
paragraph. But for our purposes, we need the newline.
Previously we handled this by wrapping `result` in a list with a newline as the
second element before calling `org-element-interpret-data`, but this interfered
with what `jupyter-org-babel-result-p` (called by
`jupyter-org--wrap-result-maybe`) expected as its argument. With this commit,
the result is never wrapped in a list.
