Emacs dynamic module that implements foreign function interface for python. It allows usage of python modules in Elisp.
https://github.com/813gan/emacs-python-ffi
There is no binary distribution now, so you need development tools to compile this module.
System dependencies:
- make
- GCC
- pkg-config
- python>=3.10 with development tools; it essentially means header Python.h must be present. On Debian/Ubuntu you need package python-dev.
If you compiled Python yourself and want to use it, then compile Emacs Python FFI with venv activated,
or export PYTHON= with path to your exeutable before compilation.
Custom Python build needs to be ./configure d with --enable-shared flag.
Elisp dependencies:
- python-environment
NOTE for GitHub users: As of beginning of 2025 GitHub don’t display function definitions in repository overview. See rendered github page instead.
This module is going to (See Bugs and limitations) utilize Python sub-interpreters to isolate Emacs modes using this module from each other. See Pyhton documentation for details.
Most of functions in this module takes subinterpreter as first argument.
Mismatch of module API version between Emacs and python-ffi. Update python-ffi to newest version. If problem persist file bug report.
attemted loading python-ffi more then once. This shouldn’t have any effect.
Starting of Python thread failed (pthread_create). Try restart. If problem persist file bug report.
One of pthread functions failed. It’s possible if Emacs was running on system with low memory. Try restart. If problem persist file bug report.
As of Python 3.13 only Main python interpreter handles signals.
It means it’s impossible to send KeyboardInterrupt to subinterpreter; (See related GH issue)
Consequently, it is impossible (or, at least i have no idea how) to implement keyboard-quit.
Thus, any long running python code could “hang” Emacs and even C-g would not work.
In my opinion it’s far more severe issue then theoretical problems of multiple Emacs modes that break each other.
I didn’t want to neither delay release of this module or change API in some undefined future so,
all revelant functions take argument subinterpreter anyway. It just don’t have any effect now.