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 method allows kernel languages to do transformations of a src-block's code
based on the parameters supplied to the src-block before sending the code to
the kernel. The method is called in `org-babel-expand-body:jupyter`. Currently
the only parameter supported is the `:dir` option of a src-block.
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
Uses the new function `jupyter-repl-font-lock-fontify-region` to fontify a REPL
buffer. This function will only fontify regions corresponding to input cells
and excludes all other regions from fontification. Regions besides input cells
correspond mainly to output from the kernel and use font-lock-face to fontify
their contents.
This allows us to remove the functions and variables related to adding syntax
properties to the output of a cell since these were previously used to avoid
syntactic fontification of the output.
Adds `jupyter-repl--syntax-propertize` which generalizes the old
`syntax-propertize-function` to handle regions containing both cell code and
cell output.
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.
