Previously stream results would be placed directly inside the RESULTS drawer.
The issue with this is that sometimes the stream results can be represented as
org syntax.
Instead of inserting stream results directly into a RESULTS drawer, insert them
as either fixed-width or example-block org elements depending on
`org-babel-min-lines-for-block-output`. In addition, coalesce all stream
results so that multiple stream messages in succession produces only one
fixed-width or example-block element.
This may still not be the best place to put buffer modifications, but it
"spreads out the logic" a little more and simplifies
`jupyter-org--append-result`.
It seems `org-element-latex-fragment-parser` expects that a latex fragment can
really be parsed because there were false positives when it was called trying
to parse a latex environment such as `\begin{equation*}...\end{equation*}`. It
would consider `\begin{equation*}` as the fragment.
Also update the default code context for completion requests to be the current
line up to `point`.
This allows completion in python kernels to work as expected. Previously when
sending the whole line, the python completer would not return expected results.
For example, if you had something like
os.mkdir(os.path.|, 0777)
then you would not receive any completions for the os.path namespace, only for
the global namespace.
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.
Previously, when propertizing the output of the REPL, a regular expression was
generated every time to take into account the comment characters of the kernel
language. Adding this variable ensure that we only create the expression once.
Also move the function to jupyter-client.el from jupyter-repl.el
* jupyter-repl.el (jupyter-repl-display-traceback): Do it.
* jupyter-client.el (jupyter-display-traceback): Do it.
`jupyter-iopub-message-hook` is called in a channel's `jupyter-handle-message`
method, but setting the execution state should be independent of the value of
`jupyter-inhibit-handlers. So move setting the execution state into the
client's `jupyter-handle-message` method.
If the `text/html` results returned from the kernel contain an XML prolog then
use `libxml-parse-xml-region` to parse the results otherwise use
`libxml-parse-html-region`.
* jupyter-mime (jupyter-insert-html): Do it.
* test/jupyter-test.el (jupyter-html-output): Add test for html output.
