From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Newsgroups: gmane.emacs.devel Subject: Re: Common Lisp in Emacs (lisp-mode, font-lock, SLIME, SLY, ...) Date: Sat, 11 Apr 2020 16:38:27 +0100 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000ce233505a305a4dc" Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="19464"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Luke Gorrie , Spenser , YUE Daian , Helmut Eller , emacs-devel To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Apr 11 17:39:18 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jNIE1-0004wa-Iq for ged-emacs-devel@m.gmane-mx.org; Sat, 11 Apr 2020 17:39:17 +0200 Original-Received: from localhost ([::1]:52982 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jNIE0-0003WT-Kg for ged-emacs-devel@m.gmane-mx.org; Sat, 11 Apr 2020 11:39:16 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:45214) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jNIDR-0002z8-Cn for emacs-devel@gnu.org; Sat, 11 Apr 2020 11:38:43 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jNIDP-0007IU-VW for emacs-devel@gnu.org; Sat, 11 Apr 2020 11:38:41 -0400 Original-Received: from mail-io1-xd29.google.com ([2607:f8b0:4864:20::d29]:34879) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1jNIDP-0007I4-Nd for emacs-devel@gnu.org; Sat, 11 Apr 2020 11:38:39 -0400 Original-Received: by mail-io1-xd29.google.com with SMTP id w20so4707697iob.2 for ; Sat, 11 Apr 2020 08:38:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=o9nlQUBSVI1BXcyE+fhQVb8E8yNLQR8mBoePPCVBkYc=; b=ForJkIXnflpbwXCReqKeVadSXetvZPylYg9ZXdD5/kH4myFLsctDGsiRcgE4bhW2ih GJXgrbjkVF86aqPsFIkhIlBuVPemkp6fDYwDUKqyoMQAkvJw0fLiUAX2WmJ/gT5tU6vS 5r4pq/VI64vKApXfEJp9eC81puMP94b7Kcng1olY+ZHqHtDnM17/w5lDQQvsXDKAs3K8 c6C948ceDapCDqZL0v2oykLHB1/w9G8chBd77zjGnguVT5dyEIQ9DZA6DZmwFdIZ68oA k/H99xwXHjBSEZmCmRY1bGc9dPh3PNUBg2ynMz4jENi9kXbe2S5DidziuWBIQhTaOTUR vFjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=o9nlQUBSVI1BXcyE+fhQVb8E8yNLQR8mBoePPCVBkYc=; b=XtJjewMgTloJIpP+ZfwQFlvZr2t0SJ2j1Ixhwq+d7cGmGz5akrWMALRShUjHyPaZsI ZQze4A4Vh4QvI4owkmNGixIsrya1+YzeA18J5mrubg2Nt6xQETQFKQUtwAKkSiYOBVyy gxme6GM2NiFftHpF0U7tXLRBjhRnobuFzFqPRTbnqAvAfTXlZUTAJFO2mYkh2adje0Tu 1WwIJWVn/le0eQ1Z7tPd43/h5Kj2NqpE8l3XUFuUjaEHNAs53uixRR+gfhR1WOOJL9sQ YgrW/ucyZjiKF221DGGzuC7esbRSAiXZH7LDUKFfGo0gAr+JOVTcnvdGWzue1pl0kYwJ pcDw== X-Gm-Message-State: AGi0PuZexdHWmds26sFkQFOkYYrvgvxvT18Z8bFCCiQ5lzw9Ia/sLmaT A/XvrNFAydqzom7OHwspMDyqJuHFUYUuIZw6OMk= X-Google-Smtp-Source: APiQypJpqgdkErKFePiUkkHY3gqJqNI399mB9MYxz6AjnWlr7NMA6tnbe0g3NdmYMDYcaYVtUPcXGqGSoe2/Maw1/Ww= X-Received: by 2002:a6b:c087:: with SMTP id q129mr8956669iof.57.1586619518686; Sat, 11 Apr 2020 08:38:38 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::d29 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:246838 Archived-At: --000000000000ce233505a305a4dc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Apr 11, 2020 at 12:00 AM Stefan Monnier 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=C3=A3o 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"). --000000000000ce233505a305a4dc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Apr 11, 2020 at 12:00 AM Stefan Monnier <monnier@iro.umontreal.ca> wrot= e:

> Sorry to spam here a little, but I was looking into how we s= hould
> 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`?=C2=A0 IIUC neither SLY nor SLIME actually u= se
> `lisp-mode` itself, they use some other major mode with its
&= gt; fontification function, right?

Hi Stefan, how are you?

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

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

> So do they already highlight built-in fun= ctions, types, and variables
> in a special way (presumably by queryi= ng the underlying Lisp process)?

No.=C2=A0 As far as I know, they bo= th use "static" highlighting techniques,
i.e. font-lock i.e. s= omething like:

=C2=A0 =C2=A0(defvar sly-additional-font-lock-keyword= s
=C2=A0 =C2=A0 '(("(\\(\\(\\s_\\|\\w\\)*:\\(define-\\|do-\\|wi= th-\\|without-\\)\\(\\s_\\|\\w\\)*\\)" 1 font-lock-keyword-face)
= =C2=A0 =C2=A0 =C2=A0 ("(\\(\\(define-\\|do-\\|with-\\)\\(\\s_\\|\\w\\)= *\\)" 1 font-lock-keyword-face)
=C2=A0 =C2=A0 =C2=A0 ("(\\(che= ck-\\(\\s_\\|\\w\\)*\\)" 1 font-lock-warning-face)
=C2=A0 =C2=A0 = =C2=A0 ("(\\(assert-\\(\\s_\\|\\w\\)*\\)" 1 font-lock-warning-fac= e)))

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

The corresponding code in SLY lives in contrib/sly-fon= tifying-fu.el

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

No.=C2=A0 All the extra behavior is added via minor modes, _= not_ major-mode
inheritance (but see PS).

> Do they (re)use th= e font-lock keywords of `lisp-mode` at all, or do they
> use somethin= g completely independent?

I think they reuse some of the keywords.
Jo=C3=A3o

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.=C2= =A0 I've been meaning to
migrate SLY's cross-referencing facilit= ies to Emacs's xref.el anyway,
but they're very slightly incompa= tibles 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.=C2=A0 When loaded, they both
overr= ide Emacs's built-in lisp/emacs-lisp/cl-indent.el with libraries
tha= t aren't quite the same.=C2=A0 There is a long-standing SLY issue opene= d
by Jonas Bernoulli which is currently stalled because we don't kno= w what
do do.=C2=A0 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 Lispprocess.=C2=A0 They discover the syntax of each macro and indent according= ly
(so indenting produces different results depending on whether you are=
"offline" or "online").
--000000000000ce233505a305a4dc--