李杀关于Guile和Emacs的整合的看法…有点悲观，Guile只有一个人在维护，到现在为止还没有准备好让Emacs和Guile整合。
现在纠结的是要不要做到内置里而非做不做，lsp-mode 已经搞了一段时间了，肯定会搞下去。其实我感觉对用户来说没什么区别，大不了就装个 mode 而已。
而能作为内置这件事形式意义上更大吧，毕竟一个微软推送的标准要被 RMS 放进 Emacs 里了，也是一个历史的转折。
ensime是不是和LSP的想法类似，它利用sbt/mvn等项目管理工具分析代码，包括构建，自动下载依赖的包，使得java/scala的语义补全，定义查询等是背后已经构建好的。不知道这样理解LSP对么？
你觉得如果瘦身emacs，emacs作为安静的编辑器，需要哪些功能呢？ 下面是我想到的。
- 独立于文件后缀的功能或格式需求，从语言角度，提供书写方便，如语言上的补全；语言上的检测错误等。
- 提供基于项目为单元的文本检索，查询（如projectile）。
- 支持git等版本管理系统。
- 支持主流的文本文件语义显示，如xml等。
- 支持自定义的配置。 是不是基于这个，可以给一个emacs的最小配置。。。
你需要这个。比GNU的那个小多了，上述功能全都有。就是用不了Emacs Lisp，但是这两个都支持Lisp语法，用来在Emacs挂掉以后改配置也不错。
我说的瘦身不在于 emacs 本身，而是配置文件。
spamcemacs 这样规模的项目，除了说明 emacs 可定制性以外，也反映了 emacs 很多方面的欠缺，特别是编程语言的支持。很多 package 只是用正则表达式来分析语法，比如这个定义跳转的: https://github.com/jacktasia/dumb-jump#how–it-works，内置的 pckage 应该也不少这种情况。
基于文本匹配的方式，效率和准确必然存在问题(何况 elisp 本身效率就不高)，还疲于追赶各种语言的变动。匹配字符串，不理解语义，连变量名重构这样的事都做不好。
如果把语法分析交给 server 处理，集中力量把字体／颜色／跨平台等等各种视觉方面的问题解决好。而用户只需要使用 elisp 定制写适合自己的“界面”、快捷键、交互方式等等。才是真正的造福用户。
7 个赞
感觉这样的话，GNU/Emacs的优势也就流失了。
相比其他Emacs，GNU就强在生态系统，这个生态一部分是因为RMS 作为Emacs正统作者的战略得当，一部分是因为 Emacs Lisp 强大的开发能力（也得归咎于RMS）。
所谓提供一个界面，我上面提到的两种Emacs都能做到，甚至因为没有用 Emacs Lisp ，在轻量化与高速化上做得更好，在生态系统的劣势不复存在，开发新语言支持成本大幅下降以后，至少对于开发向的用户吸引力就增强了（恐怕Linus也是由于这个理由），更不要提其他类型的编辑器了，GNU 在这时候可能也就靠 LaTeX 之类的生态积累保持对文学向用户的吸引力了，当然，这是在不考虑个人感情的情况下，但是有多少用户会有感情因素就很可疑了。 这样一来，LSP对开发向用户来说可能是好事，对GNU/Emacs 来说却足以构成威胁。本质上来说，LSP就是为了让用户能用自己喜欢的编辑器，有这个结果很容易理解。
这样一来，也就能明白为什么RMS会松口了，不松的话，对GNU的打击恐怕更大。 所以李杀的看法，也就是提升 Emacs Lisp ，的确是很有道理的，毕竟事关自己喜爱的编辑器的存亡。但 Emacs Lisp 能提升多少，就不好说了。
JavaEmacs上一次更新的时间是05年，现在还有人维护么？
它的主页没动过，不过核心解释器 Kawa 目前还在开发（相当于 Guile Emacs 的 Guile），Kawa 最近一次更新是 2017 4月 17日。 JEmacs 是附带在 Kawa 里面一起发布的， Kawa 的开发之一目的是可以直接跑现有的 Emacs Lisp 包而不用做修改，哦，主要还是做 Scheme 实现。
至少 Guile Emacs 目前一次发布都没有。唉。
1 个赞
我倒不觉得 LSP 会导致 Emacs 的优势流失。
Emacs 最吸引我的，是它的一致性。从 Windonws 到 Linux 到 macOS，从 GUI 到 CLI，从本地到远程，几乎都能保持一致的体验。
能做到这点，足以说明它的强大的定制和扩展能力。眼见的一切都能改，所想的一切都能实现，虽然不是最佳方案，但是它具备这种能力就足以甩开其它编辑器了。这种可扩展能力价值在于从无到有，而当 lsp 出现之后，再用 emacs-lisp parse 各种语言文件就有点相形见拙了。
emacs-lisp 性能的提升是有必要的，为了效率多用内存也是合理的。但即使把整个 .emacs.d 读入内存，也不能完全解决项目开发的问题。
一个项目加上第三方库，文件数量通常都是以 k 计的，如果想要准确&快速的补全，必须所有文件都 parse 一遍，然后把符号装入内存。光是这一步，就够 Emacs 吃一壶了，何况还要维持符号表的实时更新。想想看我们平时连 helm-find-files 搜索文件都要排除 node_modules/vendor…这些目录，才不会卡顿。
我们一直都在说 Emacs 的各种好，甚至连煮咖啡都要用 Emacs，可现实有时候很尴尬，不得不拿起 eclipse/android studio/Xcode…离开了 Emacs 之后，就只能开启 emacs-like key bindings 聊以自慰了。如果能接入各种 LSP Server，反倒是可以避免这种窘境。
实际上我们已经在用各种语言的 Server 了，只不过没有统一的标准，现在 LSP 出现了，有什么不好呢？
刚才在 VS Code 体验了一下基于 LSP 的 PHP 补全(GitHub - HvyIndustries/crane: PHP Intellisense/code-completion for VS Code)，虽然还在开发中，速度和准度已经远远好于我在 Emacs 上用过的所有 php-mode 了。
9 个赞
代码自动完成在目前emacs中还是不够强大， 强烈建议增强这方面的功能
1 个赞
其实，我喜欢emacs的根本原因是 lisp 的语法，其次是lisp的语言特性， 括号可以减少歧义性
ms带头的lsp，不也是开源么，要说影响emacs的血统，那也是lsp相关项目是open-source，而非free software吧，这是lsp&emacs的问题，和ms没啥关系嘛。
lsp不会使得emacs更衰落啊，只会使它拥有比如vs code一模一样的理解代码能力，这怎么看都不会使现在的用户抛弃它，反而本来限于emacs能力要vs code+emacs或者jetbrains+emacs双持的用户可以只用emacs了。
4 个赞
emacs挂掉后，我用vim改配置，hhhh
以前我用 vim 。现在觉得太大众了，不够装X，就卸了，启动不来就直接 emacs -Q改配置。
1 个赞
我重新顶上来就想问一句：“现在这事儿咋说了？”
其实最大的阻力应该还是来源于LSP的授权协议问题。这可能让FSF无法做出决定来。 这货不是GPL啊。然而GPL那恶心的传染性不是人人都喜欢的。但是如果FSF用了非GPL的代码而且不能做出一个能让人信服的解释的话，不等于打自己脸么。
不过我个人觉得，整合进LSP之后，我应该会少问很多关于各种补全后端的脑* 伸手党问题…… 毕竟我不用操心了，也不用整天想着怎么写company的那点配置了，直接交给LSP，我去写写使用习惯和界面配置就好。
你想多了。 首先这玩意已经有人在搞了，没必要让 FSF 表态。 其次，LSP 是 client server 形式交互的，Emacs不需要使用任何非 GPL 代码。Server 可以是任何商业软件或自由软件，Emacs 端的 Client 只要是 GPL 的就没问题。
很多人用这种方式做到用 GPL 代码却不完全开放源码。即 Server 或者 Client 中的一个是开源的，另一个可以私有。
然后，XEmacs 就是一个用到非自由软件的前例。搞个 fork 并不需要 FSF 同意，只要用 GPL 发行就可以。
好吧……我傻x了…… 不过LSP看来是解放“不用IDE”的人的一大利器啊。