GNU-devel ELPA - drepl

To start a REPL, use one of the M-x drepl-* commands (making sure first that you have the target language dependencies installed, as described above). The rest should look familiar.

It is also possible to interact with a REPL from another buffer, say to evaluate a region of text. The relevant commands are the following:

• drepl-associate: By default, dREPL tries to guess which REPL is the right one for any given buffer; an error is raised if there is no good guess. In this case, you can manually create an association with this command.
• drepl-pop-to-repl: Go to the REPL associated (implicitly or explicitly) to the current buffer.
• drepl-eval: Evaluate a string read from the minibuffer.
• drepl-eval-region and drepl-eval-buffer: Evaluate text of the current buffer.
• drepl-restart: Restart the interpreter. In IPython this is a soft reset; use a prefix argument to kill and start again the interpreter.

Documentation on a symbol in the REPL buffer, if available, can be accessed with eldoc-doc-buffer.

This package extends Comint and so the communication between Emacs and the interpreter happens through a pseudoterminal. The conundrum is how to multiplex control messages and regular IO.

• From the subprocess to Emacs, control messages travel in JSON objects inside an OSC escape sequence (code 5161).
• From Emacs to the subprocess, control messages are passed as lines of the form ESC = <JSON object> LF. If the subprocess communicates over a PTY and the encoded message is too long to fit a line (this is an OS-dependent limit), then the message payload is split into fragments. All fragments except the last are transmitted as ESC + <JSON fragment> LF.

At any given point in time, the subprocess expects either a framed messages like this or regular IO. Emacs keeps track of the state of the subprocess through status notifications as described below.

There are three types of message: requests, to which a response is expected, and notifications, to which no response is expected. A message contains the following fields:

• op: The operation name. It must be present in every notification and request but is absent in response messages.
• id: A unique number which should be present in every request and repeated in the response message. It is absent in notification messages.
• Further fields are parameters specific to each type of request, notification or response.

The following operations are defined:

This package is intended to do what the good old Comint does, but polishing some rough edges. For example, completion in Comint is spotty and one is able to edit only the last line of a multi-line input.