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.
Change the behavior of `jupyter-org-sync-results` to return the org formatted
result string and modify the result parameters in `org-babel-execute:jupyter`
to add the "raw" result parameter so that the result string is directly
inserted into the buffer.
This is to work towards better support for in-lined code blocks.
There was an ugly hack that destructively modified the source block parameters
supplied to the org-babel execute function to make `org-babel-insert-result` do
all of the insertion work. This relied too much on knowing the internals of
that function. I also could never figure out how to insert stream results in a
clean way.
Instead we manually insert the results by taking advantage of the `org-element`
API. Specifically the function `org-element-interpret-data` which takes an org
syntax tree and returns its printed representation. Now the
`jupyter-org-result` method returns either a string or a syntax tree. If the
latter is returned, it is filtered through `org-element-interpret-data` to
obtain the string representation for insertion.
In addition, all source blocks insert results in a RESULTS drawer. This allows
for inserting stream output as raw text in the drawer and allows for a way to
append results since the end of the drawer acts as an insertion point.
- A `jupyter-org-client` is a subclass of a `jupyter-repl-client` and replaces
the use of callbacks in `org-babel-execute:jupyter` to handle the insertion
of code block results in an `org-mode` buffer. `ob-jupyter.el` now only
contains the integration with `org-babel` and all integration with
`emcacs-jupyter` is placed in `jupyter-org-client.el`
- Introduce `jupyter-org-request`, which inherits all of the field of a
`jupyter-request` and adds the fields necessary for keeping track of the
source code block information a request was generated from during the
lifetime of the request.
