右侧的略缩图是怎么实现的？难道通过缩放吗 
有个minimap的插件，功能什么都好用的，就是没有VSC那么丝滑。
dengste/minimap: Sidebar showing a “mini-map” of a buffer (github.com)
1 个赞
好文章。虽然题目里有 VSCode 不过主要是在讨论 NeoVim 和 Emacs 呢。我很希望有个 NeoEmacs，但 remacs 死了，emacs-ng 也不具有 NeoVim 那样的动量。
不太了解 Emacs 的内部工作方式，但我认为可扩展性和稳定性在一起就会导致灾难。Firefox 曾经也很可扩展，但每次版本更新都会导致很多插件失效。
文章还提到现代化 Emacs 缺乏收益。虽然可能还是难以吸引新用户但应该可以减少很多维护负担，就像 PGTK 那样。
Vim 的操作方式确实高效，但也确实难学。不过刚刚想起来，学了之后还可以在 Emacs 和 NeoVim 之间横跳，VSCode 上也能用，性价比还是很高的。
Emacs 好像用不了 jupyter？
minimap性能太糟糕了，实用性也不强，没有必要一定要用上
性能确实不好，默认是关闭的，目前还没发现有更好的平替
平替是每个代码文件内容不超过屏幕高度。
我觉得楼主提出了一个很重要的问题，就是：用户需要开箱即用。
如果我们一直把 Emacs 用户定义为那种凡事自己动手的典型Geek，那么像目前这样，没有任何问题。但，大部分人只是需要一个称手的工具，完成自己的工作而已。故，如果我们把 Emacs 当成一个严肃的产品，我们就不得不考虑大多数用户的需求。
1 个赞
每个软件都应该有自己的风格，特色和定位。 硬要把她装饰成另外一个编辑器的样子，最后会变成四不像。
反过来，去VSCODE社区问，有没有一个类似Emacs一样的配置？全键盘，C-x b 操作 buffer 等？
喜欢 Emacs 就尝试去感受她原有的样子，最后，你可能会爱上她。
2 个赞
如果我们一直把 Emacs 用户定义为那种凡事自己动手的典型Geek，那么像目前这样，没有任何问题。但，大部分人只是需要一个称手的工具，完成自己的工作而已。故，如果我们把 Emacs 当成一个严肃的产品，我们就不得不考虑大多数用户的需求。
我认为，即使是 Geek，开箱即用也很重要。我挺喜欢折腾的，但我折腾一个工具一般都是用了一段时间之后有不满意的地方。如果一开始上手都很困难，需要折腾很久才能用着舒服，那就有一个风险：我折腾半天都没法开始使用，那么我最后能不能折腾到非常顺手的地步呢？这个是不确定的。
Doom 就提供了一个开箱即用的配置，当然是对于 Vim 用户。不需要什么配置就可以使用现代化的主题，熟悉的快捷键。上手之后，就会对 Emacs 越来越熟悉，折腾起来也会比较轻松。否则一开始折腾半天见不到成效也很劝退。
1 个赞
这么多年的生态发展，大部分需求，哪怕是细分的，都有解决方案，其实大部分像我这样的新手都是摘抄前人的配置，一点点积累起来形成了自己的配置。所以我感觉不存在尝试了不成功的路，形成自己配置的过程也就是解决问题的过程，这个过程才会了解自己真的需要的是什么。
vscode刚出来的时候是只能用json配置的，我感觉对于身边很大一部分用户而言，像vscode那样用json配置文件都受不了，就必须得用GUI点点点才行，对于这种用户我觉得是不可能接受去用elisp来写配置的，直到后来vscode也能用gui开始配置了，才开始大规模的流行起来。emacs的那个customize的那个界面我感觉做的是根本没办法用，和vscode的那个gui界面没办法比。我估计emacs社区应该也很难有人有动力去开发一个媲美vscode界面的gui界面，毕竟但凡能接受使用vim/emacs的用户，都应该习惯了使用纯文本去配置，而不是点点点。
还有一点就是vscode基本上每一种语言都对应了一种完美bundle好的开箱即用的插件全家桶，用户基本上用啥语言就只只装一个插件就够了。但是对于emacs而言，根本没有一个类似于微软官方这样的存在去给你把一个语言所需要的基本功能都给你做成一个全家桶插件都bundle好，那用户要使用就必须得自己去东下下插件西下下插件，再读读文档，选好自己满意的配置才能用。
1 个赞
如果经常换电脑或者有很多的话应该不会想这样吧，每个重新点一遍？
vscode可以同步配置的啊
那个需要登陆 github 的插件吗
然后每台机器登陆一下？ 而且还要每台机器都能翻墙吗？
感觉就是解决一个问题，但是又引入了别的问题
vscode又不是专为国人开发的，我们不能正常上github,不代表其他国家的使用者不能正常使用啊。
vscode的大部份使用者应该都能用github。
Emacs 用户从github装插件不一样很多嘛。
就这样，我用emacs。Peace。
我同意 Jousimies 的说法,这个时候考虑github,翻墙这件事完全没必要,应为emacs有一堆插件都是github上,melpa上找不到.这个时候镜像就不管用了(虽然我只要不在melpa上就并引用,现在都没用上lsp-bridge).而且vscode的鼠标点点点也是生成配置文件的,备份该文件也能做到多端同步
这么多年的生态发展，大部分需求，哪怕是细分的，都有解决方案，其实大部分像我这样的新手都是摘抄前人的配置，一点点积累起来形成了自己的配置。所以我感觉不存在尝试了不成功的路，形成自己配置的过程也就是解决问题的过程，这个过程才会了解自己真的需要的是什么。
一个新手可能会担心的问题：
- 我是不是目标客户？
- 我需要投入多大精力？
- 我最后能获得多大回报？
Emacs 虽然是一个成熟生态，但仍相对小众，很难保证每个需求都有解决方案。或者说，Emacs 的解决方案是你想用什么就自己配置，什么都能做到。但对于新手很难摸清到底难上手是多难，扩展性强是多强。即使我已经用了几年的东西也会经常发现自己一直想实现的需求有很好地解决方案了。
那么开箱即用的话，我可能半天就知道这个东西适不适合我了。可能不能 100% 满足我的需求但可以很快满足 95%。而 Emacs 则是可以满足 100% 的需求，但一年之内都不知道怎么才能做到。
还有一点就是vscode基本上每一种语言都对应了一种完美bundle好的开箱即用的插件全家桶，用户基本上用啥语言就只只装一个插件就够了。但是对于emacs而言，根本没有一个类似于微软官方这样的存在去给你把一个语言所需要的基本功能都给你做成一个全家桶插件都bundle好，那用户要使用就必须得自己去东下下插件西下下插件，再读读文档，选好自己满意的配置才能用。
VSCode 上虽然微软提供了一些插件，但还有很多是社区提供的。VSCode 毕竟用户多，什么时候 Emacs 有这么多用户问题就都解决了。当然这是个鸡蛋问题。不过有了 LSP 感觉这方面问题不大。Emacs 如果有更好的策展的地方应该能解决发现插件的问题。
那个需要登陆 github 的插件吗 然后每台机器登陆一下？ 而且还要每台机器都能翻墙吗？ 感觉就是解决一个问题，但是又引入了别的问题
有个用 Gist 同步的插件，当然是被墙了。也有大局域网专供的用 Gitee 同步的插件。用 Syncthing 同步也可以，免得泄露隐私。Emacs 的配置怎么同步 VSCode 就可以怎么同步，都是文本文件。
图形化界面的意义感觉应该是帮助新手快速入门，而不是一直用下去。入门之后应该放弃才对。 我觉得参照 .htaccess文件在线生成器 这样的办法生成配置就不错。
vsc高级用户我感觉应该和emacs用户一样也是的较少使用图形界面点来点去，而是自己写配置、插件。不知道这个感觉对不对。
1 个赞
我来补充一个链接：
Emacs VS(Code)
3 个赞