emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Common Lisp in Emacs (lisp-mode, font-lock, SLIME, SLY, ...)


From: João Távora
Subject: Re: Common Lisp in Emacs (lisp-mode, font-lock, SLIME, SLY, ...)
Date: Sat, 11 Apr 2020 16:38:27 +0100

On Sat, Apr 11, 2020 at 12:00 AM Stefan Monnier <address@hidden> wrote:

> Sorry to spam here a little, but I was looking into how we should
> integrate something like cl-font-lock
> (https://github.com/cl-font-lock/cl-font-lock) into Emacs and then
> I started to wonder...
>
> Who uses `lisp-mode`?  IIUC neither SLY nor SLIME actually use
> `lisp-mode` itself, they use some other major mode with its
> fontification function, right?

Hi Stefan, how are you?

No. Both SLY and SLIME use lisp-mode. They augment it with minor modes
which are added to lisp-mode-hook. slime-mode and sly-mode are such
minor modes and they are active wherever Lisp-related features are
required (finding definitions, describing symbols, inspecting values,
etc).

SLY differs slightly from SLIME in that it additionally has the
sly-editing-mode minor mode, which turns on source-code editing
facilities (which shouldn't be active in other non-source buffers where
some SLY functionality is active).

> So do they already highlight built-in functions, types, and variables
> in a special way (presumably by querying the underlying Lisp process)?

No.  As far as I know, they both use "static" highlighting techniques,
i.e. font-lock i.e. something like:

   (defvar sly-additional-font-lock-keywords
    '(("(\\(\\(\\s_\\|\\w\\)*:\\(define-\\|do-\\|with-\\|without-\\)\\(\\s_\\|\\w\\)*\\)" 1 font-lock-keyword-face)
      ("(\\(\\(define-\\|do-\\|with-\\)\\(\\s_\\|\\w\\)*\\)" 1 font-lock-keyword-face)
      ("(\\(check-\\(\\s_\\|\\w\\)*\\)" 1 font-lock-warning-face)
      ("(\\(assert-\\(\\s_\\|\\w\\)*\\)" 1 font-lock-warning-face)))

The only example of font-locking by querying the underlying Lisp process
happens for reader conditionals like #+foo.  The reader conditional is
evaluated in the underlying Lisp process and decides if the form
following the #+foo is fontified as a comment or not.  I don't know
_exactly_ how this is done (didn't touch this part of the fork much).

The corresponding code in SLY lives in contrib/sly-fontifying-fu.el

> Do they actually use a proper child-mode of `lisp-mode`?

No.  All the extra behavior is added via minor modes, _not_ major-mode
inheritance (but see PS).

> Do they (re)use the font-lock keywords of `lisp-mode` at all, or do they
> use something completely independent?

I think they reuse some of the keywords.

João

PS: The only exception to this is sly-xref-mode and slime-xref-mode,
which do infact derive lisp-mode but it's basically a hack on both
counts, it doesn't really use most of lisp-mode.  I've been meaning to
migrate SLY's cross-referencing facilities to Emacs's xref.el anyway,
but they're very slightly incompatibles and I haven't had the time to
merge the two.

PS-2: By the way, IMO cleaning up the indentation code is something more
pressing in terms of well-behaving SLY/SLIME.  When loaded, they both
override Emacs's built-in lisp/emacs-lisp/cl-indent.el with libraries
that aren't quite the same.  There is a long-standing SLY issue opened
by Jonas Bernoulli which is currently stalled because we don't know what
do do.  See
https://github.com/joaotavora/sly/issues/92#issuecomment-329559333 and
maybe offer your advice there.

Also note that indentation is where both SLY and SLIME do query the Lisp
process.  They discover the syntax of each macro and indent accordingly
(so indenting produces different results depending on whether you are
"offline" or "online").

reply via email to

[Prev in Thread] Current Thread [Next in Thread]