VSCode这两年发展太迅猛了，我2019年还认真用过一个月，客观的说代码补全确实做的好，很多交互细节也做的很贴心，最后放弃是因为很多操作还是要用鼠标，我个人受不了鼠标和键盘的频繁切换。
俗话说，打败VSCode不光要靠自由软件的信仰和坚守，更要吸收‘敌人’的优点，学习敌人就是最好击败敌人的方法。
大伙没事的时候可以拔一下VSCode的插件商店和更新日志, 一起讨论一下VSCode插件的优点。
比如有哥们就研究 GitLens 然后仿写了一个 blamer.el, 我觉得挺好用的，比 magit 的 blame 功能还好用。
大伙发挥群力，可以一起拔一拔优秀的插件，没事大家下班讨论一下，觉得好的插件，论坛的大佬们一起来移植到Emacs中，要爽一起爽。
vscode 的 release notes 其实包含挺多东西的，有时候更新了我就去翻翻，很多 feature 都有 GIF 示例，挺不错的。
之前九月份的 release notes 中发现一篇关于括号匹配的算法 How We Made Bracket Pair Colorization 10,000x Faster In Visual Studio Code （没细看，大概能改善一下 emacs indent-guides 的性能问题？
是啊，这些都是他山之石，可以为我们所用。
我觉得大家没事可以拔一拔，vscode还是很多优点可以被吸收的。
我看了这个文章，主要是vscode基础设施做的好，有完善的AST, emacs目前还是主要靠正则表达式交叉搜索来语法高亮。
这个 blamer.el 在 Windows NT emacs 没法用，开启以后卡的很 
。
最近有大佬搞了个加强版的 github-review，GitHub - wandersoncferreira/code-review: Code Reviews in Emacs ，感兴趣的可以试试看。
不过在这个方面应该还是 vscode 的 github 插件比较强。
他山之石可以慢慢搬，我现在觉得除了Emacs的 LSP 性能太渣，在大体方面不输VSCode, 特别是键盘流的流畅性上。
我也看到了，如果这个插件能够支持临时合并就好了，我目前是用EAF上Github来做Code Review的。
期待猫哥的 lsp-bridge 能够解决这个难题
LSP主要这玩意第一把顶层设计的时候太耗费精力了，我弄 LSP 最怕的其实是后面无穷无止的 Issue 啊， 想着都，恩…可怕。
tree-sitter 好像能顺便解决掉 AST 的问题？之前 emacs-devel 好像在讨论这个问题。
其实一直想把 LSP 的代码跳转功能单独抽出来做一个 source insight 的类似物。就是工程量大，加上主要使用的 C++ ，漏符号一直存在的话做出来意义也没那么大，就搁置了很久。
gitlens看起来和jetbrains里默认的git功能类似
indent line这玩意做的好，要引入和代码层无关的像素绘制层专门画垂直线。
现在都是基于overlay模拟的，会受到字体宽度影响，而且性能还不好
还有一个，就是vscode的 Code Spell Checker 做的也很好，使用了cspell这个检查工具，或许可以写一个emacs pacakge来集成一下，我目前是用 (compilation-start "cspell" 'grep-mode))的方式来使用，还是不大方便
`highlight-indent-guides’ 是通过动态生成 PBM bitmap 来实现，不会用到 overlay 或受到字体宽度影响，而且性能还不错。
就是 highlight-indent-guides 这个插件的性能很差， 我已经禁用了。
我用了一下，没有感到有啥问题
我学完Emacs LIsp也来参战 
不过不确定他创建 bitmap 的方式会不会影响 image cache，导致内存消耗太高
当然，这种功能最好的实现办法应该是在 redisplay 添加 “empty-glyph-display” 这样的 display property，可以在stretch glyph 和其他的 glyphless glyph 中显示不同的画面，不过现在 lisp 端也能够实现吧