现在纠结的是要不要做到内置里而非做不做，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”的人的一大利器啊。
LSP 这事之前我就在想过，没想到真有人搞出来。就是万万没想到竟然是微软牵头 ……
不管怎样，对 LSP 我是举双手赞成的。用过文本编辑器补全功能的相信都能理解，之前各种良莠不齐的实现，功能各种残缺不全，还有莫名其妙的 bug …… 而 LSP 则把后端解析彻底分离，有利于大家集中力量搞一套实现，不管用 vim 的，用 emacs 的，用 atom 的 …… 都可以给 server 端贡献代码。至于一直被人诟病的 IDE 功能如语义理解、重构、远程server 等等也能实现。所以你们到底是在反对什么？！
至于说 LSP 会削弱 emacs 独特性、竞争力的，坚持要用 elisp 实现一切想要的功能的，且不说该语言极其极其小众，老旧，晦涩，就说会有多少人会为了用一个编辑器“专门”去学一门语言呢？
判断一个东西是否有光明前景，观察一下同样条件下有多少“新手”流入流出，可以做出一个大致的结论。这不禁让我想起那个 maestro 和学徒的对话，maestro 最后说：魂淡，你以为我还想再多学一个新的编辑器么？我想，用 sublime text、atom 的学徒们的内心 os 也同样会是：魂淡，你以为我想学那个老得掉牙的编辑器么？
PS：目前 emacs 还在和一堆别的编辑器混用着，你可以把该帖理解为吐槽贴 ⚆_⚆
1 个赞
我的感觉就仿佛布尔什维克看到无信仰者。
╮(￣▽￣"")╭