VSCode 狗仔队计划

VSCode这两年发展太迅猛了,我2019年还认真用过一个月,客观的说代码补全确实做的好,很多交互细节也做的很贴心,最后放弃是因为很多操作还是要用鼠标,我个人受不了鼠标和键盘的频繁切换。

俗话说,打败VSCode不光要靠自由软件的信仰和坚守,更要吸收‘敌人’的优点,学习敌人就是最好击败敌人的方法。

大伙没事的时候可以拔一下VSCode的插件商店更新日志, 一起讨论一下VSCode插件的优点。

比如有哥们们就研究 GitLens 然后仿写了一个 blamer.el, 我觉得挺好用的,比 magit 的 blame 功能还好用。

大伙发挥群力,可以一起拔一拔优秀的插件,没事大家下班讨论一下,觉得好的插件,论坛的大佬们一起来移植到Emacs中,要爽一起爽。

25赞

vscode 的 release notes 其实包含挺多东西的,有时候更新了我就去翻翻,很多 feature 都有 GIF 示例,挺不错的。

之前九月份的 release notes 中发现一篇关于括号匹配的算法 https://code.visualstudio.com/blogs/2021/09/29/bracket-pair-colorization (没细看,大概能改善一下 emacs indent-guides 的性能问题?

1赞

是啊,这些都是他山之石,可以为我们所用。

我觉得大家没事可以拔一拔,vscode还是很多优点可以被吸收的。

我看了这个文章,主要是vscode基础设施做的好,有完善的AST, emacs目前还是主要靠正则表达式交叉搜索来语法高亮。

这个 blamer.el 在 Windows NT emacs 没法用,开启以后卡的很 :smile:

最近有大佬搞了个加强版的 github-review,https://github.com/wandersoncferreira/code-review ,感兴趣的可以试试看。

不过在这个方面应该还是 vscode 的 github 插件比较强。

1赞

他山之石可以慢慢搬,我现在觉得除了Emacs的 LSP 性能太渣,在大体方面不输VSCode, 特别是键盘流的流畅性上。

我也看到了,如果这个插件能够支持临时合并就好了,我目前是用EAF上Github来做Code Review的。

:+1: 期待猫哥的 lsp-bridge 能够解决这个难题

LSP主要这玩意第一把顶层设计的时候太耗费精力了,我弄 LSP 最怕的其实是后面无穷无止的 Issue 啊, 想着都,恩…可怕。

2赞

tree-sitter 好像能顺便解决掉 AST 的问题?之前 emacs-devel 好像在讨论这个问题。


其实一直想把 LSP 的代码跳转功能单独抽出来做一个 source insight 的类似物。就是工程量大,加上主要使用的 C++ ,漏符号一直存在的话做出来意义也没那么大,就搁置了很久。

gitlens看起来和jetbrains里默认的git功能类似

我感觉vscode的indent line做的比较好,这点emacs的几个都不太行,最近vim也有了一个新的叫 indent-blankline 或许可以参考下实现

indent line这玩意做的好,要引入和代码层无关的像素绘制层专门画垂直线。

现在都是基于overlay模拟的,会受到字体宽度影响,而且性能还不好

1赞

还有一个,就是vscode的 Code Spell Checker 做的也很好,使用了cspell这个检查工具,或许可以写一个emacs pacakge来集成一下,我目前是用 (compilation-start "cspell" 'grep-mode))的方式来使用,还是不大方便

`highlight-indent-guides’ 是通过动态生成 PBM bitmap 来实现,不会用到 overlay 或受到字体宽度影响,而且性能还不错。

就是 highlight-indent-guides 这个插件的性能很差, 我已经禁用了。

我用了一下,没有感到有啥问题

我学完Emacs LIsp也来参战 :smiley:

不过不确定他创建 bitmap 的方式会不会影响 image cache,导致内存消耗太高

当然,这种功能最好的实现办法应该是在 redisplay 添加 “empty-glyph-display” 这样的 display property,可以在stretch glyph 和其他的 glyphless glyph 中显示不同的画面,不过现在 lisp 端也能够实现吧