lisp-semantic-hl.el: Lisp 语义高亮，现已加入 melpa

Emacs-Lisp
1

这个就是我们去年五月份在坛子发布的 Elisp fuzzy complete和Lisp动态高亮 ，原名叫做 colourful ，是我们一个同名的 LispWorks 编辑器插件的 Emacs 移植版，最近好好打磨了一番成功投稿melpa了qwq

——基于全局 Lisp 环境信息的、 Common Lisp 与 Emacs Lisp 语言的 Emacs 语义语法高亮插件

image
image3750×3008 1.62 MB

效果类似于 LSP 提供的语义语法高亮功能（lsp-semantic-tokens-mode / eglot-semantic-tokens-mode），可以高亮 lisp 函数、宏、全局变量、局部变量定义、函数参数定义、类名/类型/结构体、包名、特殊操作符（special operator）、读取器宏（reader macro），等等——除了局部变量引用外的几乎全部语义类型。鉴于 Lisp 的特殊性，基本上是无侵入的情况下能做到的极致了。

相比去年发布的 primitive 修复了许多 bug，大家有什么建议 / 捉虫可以开 issue ，也可以直接在这里反馈喵

新春快乐～

13 个赞
2

赞美老婆owo 辛苦了喵

1 个赞
3

是不是和这个类似啊 GitHub - cireu/elispfl: Extra font lock made your Emacs lisp mode fancy

1 个赞
4

是一样的idea诶，都是基于query global environment的

5

是啊, 我说看起来很眼熟

6

经过Reddit网友提醒，才知道 Emacs 31 已经内置了 elisp 的 semantic highlight 了，可以通过(setopt elisp-fontify-semantically t)开启，用起来很舒服=w=～

什么时候 CL 才能有真正的 LSP 呢（叹气

1 个赞
7

SICL 项目正在做有完整编译器支持的语义化高亮/智能补全，不过据我最近了解

  • 一是他们这个子项目负责人并非全职，进展不快，
  • 二他们是在用 CLIM 做类 Emacs 编辑器，目前没有支持 GNU Emacs 的计划，更是完全不打算做 LSP 协议的支持。

当然他们已经有一些不错的工具库可以直接用了。如

项目最近的功能演示

<beach> scymtym: So you use the s-expression-syntax library on that code, yes?
<scymtym> beach: yes, that one uses s-expression-syntax and recursively at that but no macro expansion
2 个赞
8

工具看上去不错诶。可惜CLIM前端实在不是很看好…在这个X11已经大半个身子埋进历史垃圾堆的时代McCLIM还在依赖CLX backend，SDL2 backend分支的最后一次提交在两年前，而SDL3已经问世，整个CL世界却连binding都还没有。McCLIM长期只有Kochimanski一个人，他同时还要兼顾ECL的工作。感觉这些人如果有钱有闲不如去支持McCLIM的开发，否则他们难道想让自己的应用运行在Windows + Allegro 8.0 / LispWorks上嘛——至少Windows不会抛弃Win32，Linux可是真的会把X11扬了的。脏活累活没人爱干，等外部世界把现在这点东西的根基都给扬了，那就彻底没得玩了呀（

满纸荒唐言一把辛酸泪（（

1 个赞
9

选 CLIM 是因为路径依赖，McCLIM 的原作者就是 SICL 原作者 “beach” Robert Strandh，他重新发掘出 CLIM 标准在 ACL/LispWorks 之外写出个开源实现的意思就是他以后的项目都能用 McCLIM 作为 GUI 库，不用重新造轮子，只不过过往项目他写完第一版就放生了，后续更新全靠有缘人，据说 SICL 规划完（目前还差原生编译后端）他还要回头继续完成 Lisp Machine 风格的操作系统的坑，这一整套到时候都是要上这个操作系统的，所以坚持不引入需要依赖 C 和 Unix 的东西。

XWayland 反正目前还会在，那继续用 CLX 也没啥不好的，至少可以再撑 10 年。而且 McCLIM 官方后端只有 CLX 实际上原因是它不需要 FFI 调用 C 代码，稳定性最有保障，没有大更新就说明 Robert Strandh 的 Debian Linux 最新稳定版上它还能跑。

2 个赞