* Rename `jupyter-repl-output-buffer-marker` to `jupyter-output-buffer-marker`
* Rename `jupyter-repl-output-buffer-last-request-id` to
`jupyter-output-buffer-request-id`
* Add `jupyter--reset-output-buffer-p` which returns non-nil if the current
input buffer should be reset.
* Simplify the `jupyter-with-output-buffer` macro
* Rename `jupyter-repl-with-output-buffer` to `jupyter-with-output-buffer`.
* Replace uses of `jupyter-repl-with-doc-buffer` with
`jupyter-with-output-buffer`. The difference between the two was that
`jupyter-repl-with-doc-buffer` always reset the buffer before inserting new
output.
This function is essentially the same as `jupyter-repl-insert-data` but also
allows different kernel languages to do post-processing to the inserted data.
This is done by defining a new method, `jupyter-repl-after-insert-message`
which is called with the buffer narrowed to the inserted data.
One of its uses is to fontify documentation strings of Python kernels when
making inspect requests.
This change is required because when evaluating code in other contexts than the
REPL, the convention is to set `jupyter-inhibit-handlers` to `(not :status)` so
that the `execution-state` can be updated for the mode-line construct.
* Declare undeclared external functions
* Add ext: prefix to filename of external packages that may not be present on
every system
* Remove `company-grab-symbol-cons` function declaration since this function is
no longer used.
* Previously any odd number of quote characters in the output of a cell messes
up fontification of the next input cell since it will consider the input as
part of a string. I had mistakenly thought that changing the syntax of the
quote characters when inserting cell output fixed the problem but did not
realize that as a part of fontification, the region being fontified is
unfontified first by `font-lock-unfontify-region` whose default
`font-lock-default-unfontify-region` removes the `syntax-table` property if
`font-lock-syntactic-keywords` is non-nil for a major mode which means the
`syntax-table` property that we add in the cell output gets removed.
* The solution is to add our own `syntax-propertize-function` which calls
`jupyter-repl-propertize-output` when attempting to fontify a region that
is not cell code and calls the REPL languages `syntax-propertize-function`
if available.
* In `jupyter-repl-propertize-output`, also change the syntax of ' characters
Since evaluation functions like `jupyter-repl-eval-string` inhibit handlers
except the status handler it makes more sense to do this in the status handler
as well.
Currently this function changes the syntax of " characters in inserted output
so that they do not get recognized for syntactic fontification. Syntactic
fontification should only happen for cell code.
* Move the setting of `parse-sexp-lookup-properties` to
`jupyter-repl-initialize-fontification` from `jupyter-repl-mode`
* Use the language mode's `syntax-propertize-function`, but only propertize
regions that contain cell code.
* Define `jupyter-load-language-support` which takes a client and loads the
language support definitions of the client's kernel language.
* Call `jupyter-load-language-support` when initializing a REPL buffer in
`jupyter-repl-mode`. Note this also takes care of loading the kernel support
for a `jupyter-org-client' since a REPL buffer is setup before evaluating any
`org-mode` source code blocks.
* Move language specific methods to their own files named `jupyter-LANGUAGE.el`
Sometimes when inserting output in the REPL buffer, JIT font-locking takes
place before we are able to add the text properties preventing it from running
on cell output. This happens, for example, when inserting HTML output in a
Haskell kernel. Since cell output should never be font-locked by the REPL
buffer, explicitly disable it when inserting output.
Previously if the kernel asked for non-password input, the input sent to the
kernel would be echoed to the REPL buffer. This behavior interferes with any
output generated by the kernel in response to the input. For example calling
the license() function in a Python kernel would have the sent input
interspersed with the output generated by the license() function. Instead of
echoing the sent input, don't do anything with it.
If the first character of input cell is one of ']', ';', or '?', the underlying
Julia kernel treats the input specially as a REPL "mode", different from the
regular code input.
* Rename `jupyter-repl-after-buffer-change` to `julia-repl-do-after-change`
* Add the method `jupyter-repl-after-change` which gets called in
`jupyter-repl-do-after-change` so that kernel languages can modify the input
cell after buffer changes. The default implementation of the method does the
work that was previously done in `jupyter-repl-after-buffer-change`
This was previously used to remove invisible characters from the cell input due
to invisible characters previously added by continuation prompts. These
characters are no longer inserted so there is no need for this function. Also,
there are situations where invisible characters should still be a part of the
cell code, for example when hiding the REPL mode character for the Julia
kernel.
* Add `jupyter-repl-prompt-string` to get the text of the current REPL prompt
* Allow `jupyter-repl-cell-prompt` to be given a face to use for the prompt
string
* Only mark and unmark a cell prompt as busy, if the current cell prompt looks
like it can be marked or unmarked, i.e. is the standard input prompt
These changes are in preparation for emulating REPL modes that some languages
implement such as Julia, which updates the prompt to indicate which mode it is
in.
