加1，这样对于丐中丐电脑比较友好
其实确实关隘不在emacs本身，而在于生态都不围绕 -nw, 比如 lsp-mode，-nw 下的支持显然是次优先级的，很多显示的bug。emacs 的核心团队对重点的生态项目应该多支持一下。
这个是lsp-mode自己的问题吧? 你说的问题, 需要外围的包开发者配合才行,
如果Emacs支持高级的C/S模式, 核心开发人员可能就会更专注于server端功能. 然后外围的开发人员也会认真考虑不同的GUI前段适配.
跟emacs的overlay有什么区别? 看上去右边多出来一块, 相当于emacs里两个overlay?
tty 支持主要因为终端模拟器太垃圾才没人愿意维护，看看 kitty 维护者夜郎自大就知道了，没有人愿意费时间去和这些人辩论。除此以外，你还可以看最近 tty menu 导致的一大堆 bug 来了解这方面的困难。
再说，Emacs的很多高级功能（比如说 RTL 文字）在 tty 中完全没法使用。
感觉是个很有意义的事情！
是的，Xterm 现在已经不流行了，很多新出来的的终端模拟器只支持 ANSI escape sequence 比较基本的特性。反而是把 Emacs 的终端模拟功能做好可能还实在一些。
更易拓展,稳定
可以跨window
overlay 不稳定吗？
popup的绘制时常会错位,比如下面这个截图
这是 pyim 吗？pyim 好像使用的是 posframe，不是 overlay。
即使是 overlay，也是 pyim 本身的 bug，正确使用 overlay 不会出现这个问题。
你这用的是已经被淘汰的 Emacs 23 的 popup.el，现在基于 overlay 的已经没有这问题了。
popup.el 不就是基于 overlay 的吗？
不是 overlay 不稳定，而是有局限，否则也就不需要 posframe 了。
这种错位好像是因为非等宽字体或者中英文字体大小不一致导致的, 而vim好像强制必须等宽字体. 也就是说emacs的字体支持比vim强大, 但是同时也导致了这个overlay的错位问题. 而vim不支持变宽字体, 所以规避了这个问题.
对emacs来说, 终端运行, 不存在此问题, 因为终端里面字体大小一样, 且只能用等宽字体.
对emacs的GUI来说, 可以用childframe.
好像company-box可以解决
知乎上看到一个不错的帖子：
在 vscode 遇到一个 f2 重命名当前变量名，或函数名，在一次修改后，编辑器会将当前项目中所有对这个变量名的使用，函数名的调用，跟随修改
我不知道 emacs 实现这个 feature 是什么插件有
LSP 支持这种功能，比如 elgot-rename 。
如果不用 LSP 的话，可以用 iedit 只能支持 buffer 内的修改；或者 occur 
wgrep 。
1 个赞
盲猜 vscode 这个就是 lsp 来做的吧， lsp-mode 和 eglot 也都可以