I like the python-send-buffer
command, however I very often use Python embedded in applications, or launch Python via a custom package management system (to launch Python with certain dependencies).. In other words, I can't just run "python" and get a useful Python instance (something that python-send-buffer
relies on)
What I would like to achieve is:
- in any Python interpreter (or application that allows you to evaluate Python code), import a
magic_emacs_python_server.py
module (appending tosys.path
as necessary) - In emacs, run
magic-emacs-python-send-buffer
This would evaluate the buffer in the remote Python instance.
Seems like it should be pretty simple - the Python module listens on a socket, in a thread. It evaluates in the main thread, and returns the repr()
of the result (or maybe captures the stdout/stderr, or maybe both). The emacs module would just send text to the socket, waits for a string in response, and displays it in a buffer.
Sounds so simple something like this must exist already... IPython has ipy_vimserver
, but this is the wrong way around. There is also swank
, while it seems very Lisp-specific, there is a Javascript backend which looks very like what I want... but searching finds almost nothing, other than some vague (possibly true) claims that SLIME doesn't work nicely with non-Lisp languages
In short:
- Does a project exist to send code from an emacs buffer to an existing Python process?
- If not, how would you recommend I write such a thing (not being very familiar with elisp) - SWANK? IPython's server code? Simple TCP server from scratch?
comint provides most of the infrastructure for stuff like this. There's a bunch of good examples, like this or this
It allows you to run a command, provides things
comint-send-string
to easily implementsend-region
type commands.dbr/remoterepl on Github is a crude proof-of-concept of what I described in the question.
It lacks any kind of polish, but it mostly works - you import the
replify.py
module in the target interpreter, then evaluate theemacs-remote-repl.el
after fixing the stupid hardcoded path toclient.py