The most important configurable is
which specifies the mechanism by which Lisp reads and processes
protocol messages from Emacs. The choice of communication style has a
global influence on SLIME’s operation.
The available communication styles are:
This style simply loops reading input from the communication socket and serves SLIME protocol events as they arise. The simplicity means that the Lisp cannot do any other processing while under SLIME’s control.
This style uses the classical Unix-style “
Swank registers the communication socket with an event-dispatching
framework (such as
SERVE-EVENT in CMUCL and
SBCL) and receives a callback when data is available. In
this style requests from Emacs are only detected and processed when
Lisp enters the event-loop. This style is simple and predictable.
This style uses signal-driven I/O with a
handler. Lisp receives requests from Emacs along with a signal,
causing it to interrupt whatever it is doing to serve the
request. This style has the advantage of responsiveness, since Emacs
can perform operations in Lisp even while it is busy doing other
things. It also allows Emacs to issue requests concurrently, e.g. to
send one long-running request (like compilation) and then interrupt
that with several short requests before it completes. The
disadvantages are that it may conflict with other uses of
by Lisp code, and it may cause untold havoc by interrupting Lisp at an
This style uses multiprocessing support in the Lisp system to execute
each request in a separate thread. This style has similar properties
:SIGIO, but it does not use signals and all requests issued
by Emacs can be executed in parallel.
The default request handling style is chosen according to the
capabilities of your Lisp system. The general order of preference is
NIL as a last resort. You can check the default style by
SWANK-BACKEND::PREFERRED-COMMUNICATION-STYLE. You can
also override the default by setting
SWANK:*COMMUNICATION-STYLE* in your Swank init file.