分享篇文章：为什么我会使用 Vim ？

[skywind3000]

正文请点击：

• https://www.zhihu.com/question/547708456/answer/2645630850

42楼的 @daveh 给我回了一长篇，

我强调的是 Vim 的扩展性，如何方便的让我扩展，他肤浅的理解成 vim 能做哪些， 然后按照 "Vim 只能做这些事情“ 来反驳，显然显然既不理解 Vim，他自己的 IDE 他也没弄明白。

浮窗类型提示，包括 auto 类型：

还有自动错误提示，底下一行显示。

编译运行

“这个不知道该说什么？只能说他敲了这么多字，我一个鼠标点击、或者快捷键就完成。”

他完全没理解 tasks 系统是怎么回事情，建议看看 vscode 的 tasks 系统，这个对于大 JB 是新东西。

敲不敲字根本不是重点，Vim 里绑定快捷键就是一句话的事情，我敲字是演示当前执行哪个任务。 同时表明任务多了可以用模糊匹配浏览任务有哪些，当任务多快捷键记不住很管用。

合着他还真以为连个快捷键都不支持么，可定制的任务系统，大 JB 里没有的新概念，不是大 JB 那种定义外部工具那么简单的东西，只能说他完全没看懂。

“用 JB 系，我写代码都不用通过随时编译去检查代码写对没有，不管写 Java 还是 C++还是其他语言，你把 IDE 提示标红的 Error 改完，等到构建时一次性编译通过，就是这么爽。”

对大 JB 没有的任务系统不理解，还瞎扯什么实时代码检测，他说的这个功能叫做 linter，我第一张图片就演绎了，最下面一行，vim 里能做这事请的插件一大堆：

看到没，还 ”就是这么爽“，还说自己是啥 "老 vim 党" ，vim 都没用明白的 "老 vim 党" 就是这么爽，无知真爽。

自动格式化

“严格说 PyCharm 这个功能是代码语句的自动补齐，除了自动格式化之外，还能自动补齐代码块结束符，比如 " ) ; { } 等等；如果处于代码提示选函数阶段，还能一步补齐函数名及后续代码块结束；如果写了多行，也是一次性全部格式化补全。不太相信他脚本能学到了这个程度。”

他完全搞混了，括号引号和结束符号补全 vim 里一大堆，比如 endwise，auto-pair，还有基于语义的结束补全，只是我不爱用，没给他展示而已。

自动帮助

“关于文档说说，用 JB 甚至不用自己去集成，安装对应插件就行，如 man page viewer/dash 插件。 另外 IDE 自身也提供了大量丰富的文档集成，比如他例子中的 python ，直接鼠标放上去就能看，还不满意点提示中链接查看完整文档，都不用麻烦的切换到 Dash/Zeal 窗口去看”

他以为只有大 JB 才有么？Vim 里浮窗显示文档：

他真以为 Vim 没有么，可见这个 “老 Vim 党”，用那么多年 Vim 也没用明白，再来一个：

我扩展 cppman 集成是因为 cppman 的内容来自 cplusplus.com / cppreference.com ，内容更扎实。我做 dash/zeal 集成式因为 dash/zeal 包含 50+ 种语言，可以弥补上面的不足。

我一路再说 Vim 里可以方便的扩展功能，我根本不在乎你大 JB 有没有 cppman/zeal/dash，我在 Vim 里想有就有，今天我加了 cppman 明天我可以加 tldr 或者 cheat.sh 文档，而他只能等着别人喂它，大 JB 有了他才能用。

大 JB 不支持，就傻眼了，只能嘴硬 “自己用不上”，

最后，远程编辑

"这种就远程开发了，JB 的搞个 Gateway ，体验完整 IDE 的功能。"

都跟你说了是 “临时需求”，我在外网上百台服务器里跳来跳去，每台有需求就弄一下，你要在外网正式服务器上给我每台弄个大 JB 的 Gateway，公司的运维不把你拍死才怪。

[mrqyoung]

IDE 与 VIM 并不是零和关系（博弈），而是正和关系。
据我所用过的 IDE 基本上都有 VIM 插件，仅仅是在体验、支持度、兼容度上面。比如：JetBrains
家族都有 ideavim 插件，vscode 有 VSCodeVim ，vs 有 VsVim ，Xcode 有 vim-xcode （在 xcode13 上本身支持 vim-mode ，Preferences-Text Editing-Editing-Enable Vim key buildings. 这一点我没有实际使用过所以不确定，我只在 10 版本的时候写过一点点 swift ）。
个人认为 ideavim 体验最好，而且也能按照个人喜好选择单条快捷键是按照 vim 还是 idea 本身。
原生 vim 我在 Linux 使用，以及在 win 下当轻量的文本编辑器类似 notepad 之类。

[nikolai]

现在 Neovim + LSP 已经很无脑，配制都是复制粘贴

当然不是我不想用 VSCode ，而是一开 Chrome 内存已经没了

[yuancoder]

vim 一次学习，终生收益

[danhahaha]

每次看到整理哪个工具好的时候，就像看地头俩农民争辩方头锹好还是圆头锹好。

哪个合适用那个，没有可以用一辈子的，时代在进步，新的总比旧的好，因为新的会吸取旧的教训错误缺点，否则就没人用

[daveh]

@skywind3000 #66

我来回复一下。

> 我强调的是 Vim 的扩展性

他要说肤浅，其实他这理解就是了。所谓的扩展性，现代一个稍微功能强一点的编辑器都能支持，还需要他去强调 vim 能扩展？其他编辑器就不能扩展？ JB 系不能扩展？

> 肤浅的理解成 vim 能做哪些

所以，我们只看，最终你大费周章扩展一番后，功能能支持到什么程度，能就能，不能的就不能。这没有什么吹的。

> "Vim 只能做这些事情“

显然，任何扩展，特别是脚本扩展，都是有限制的，你不能超出编辑器脚本能支持的范围，或者说编辑器开放给脚本的能力。有些功能确实你一番扩展后，也只能支持到某个程度。

> 自己的 IDE 他也没弄明白

这也是他也肤浅的地方，另外一个回贴里我讲了怎么用 JB 系原生支持的 groovy script 去扩展，还没有提怎么开发 JB 插件去扩展。groovy script 能扩展到什么程度他知道吗？因为它可以嵌入 Java 代码执行，而 JB 系又是 JVM 语言写的，这个扩展性你们去想想吧，不考虑兼容性，你可以随意用 API 操纵 IDE 。
而 vimscript ，你没法扩展出没有开放给脚本使用的功能。

> 浮窗类型提示，包括 auto 类型
> 自动错误提示

这些是 LSP 支持的功能，其他编辑器也能，并不是 vim 扩展才能。所以，他想强调的是 Vim 的扩展性，自己写个脚本就能支持了，结果又得拿一些公共领域大家都能的功能来佐证？
哦，对了，JB 系现在是直接支持在 inlay hints 中显示 auto 实际类型，并不需要弹窗，而且由于实际类型可能比较长影响代码阅读，是可以折叠的。
他说 vim 9 支持 virtual text ，能支持到 JB 这个程度吗？

> 完全没理解 tasks 系统
> 看看 vscode 的 tasks 系统
> 不是大 JB 那种定义外部工具那么简单的东西

他可能也没理解或者不知道 JB 的 Configurations 是怎么回事。VS Code 缺乏 JB 那样的项目工程管理，所以搞了这个所谓的 task 来充数，正所谓功能不够，task 来凑。JB 有工程管理概念，比如 Build 什么的都可以有标配 Configurations ，并不需要手工配置的所谓的 task 去做这些事。目前看大部分 task 其实是一些命令执行，在 JB 中用 External Tools 替代就行；少量 task ，可以用 Configurations 。Configurations 定制性也非常强，可以配合其他界面功能、其他插件功能、甚至 groovy script 使用。
JB 中按双 Shift ，也可以输入名称直接执行。

> 大 JB 没有的任务系统不理解，还瞎扯什么实时代码检测

不太理解“没有”任务系统，与实时代码检查有什么关系？这是急了吗。

> 编译运行
> 这个功能叫做 linter

JB 这个功能是实时显示代码问题，综合了 Inspect 或 Analyze 的结果，分 Error 等级别，并不是简单的 linter ，linter 只是其中一部分。
他这贴图，只看到“实时”显示了问题，并没有看到实时检查，实时检查是边改代码边检查，甚至不用保存代码，写错代码马上提示问题、并给出修改建议，改对代码问题提示自动消失。建议贴这样的图更有说服力。
另外 lint 问题并不都是 Error 必改，也可能不是问题，能编译过代码也可能弹一大堆 lint 出来，改这种 lint 不会爽。

> “就是这么爽”

他可能缺乏里面描叙的开发体验，所以才搬出个 linter 来说事，实际写新代码过程中，没人去马上关注什么 lint ，只关注当前代码有没有写错能不能编译过，JB 的这个功能，就是让你实时聚焦改当前 Error ，全部修改写完后，再去编译代码文件一步通过；代码编译通过后，再去关注那些可能不痛不痒的 lint 什么的其他检查。
所以确实有些人“无知真爽”，以为能看到个 lint 结果就爽了。

> 还说自己是啥 "老 vim 党"

我用 vim 时，这些什么 lint 、LSP 等等都还没有呢。等其他 IDE 都用烂大街了，LSP 才兴起，一众编辑器 、vim 才能借助支持了个皮毛。

> 自动格式化
> 他完全搞混了

他找到 JB 这个功能在哪没有？这个功能就是“混用”的结果，一次性搞定格式化补全等等，而且因为理解语义，不用担心补全出错误代码。
vim 搬出这么多插件，混用都不一定能达到这个效果，估计不是冲突就是要挨个来触发。这可不是爱不爱用的问题。

> 自动帮助
> Vim 里浮窗显示文档

他要是看全了，就不会简单理解自动帮助就是浮窗显示了。
写代码时自动提示候选函数文档方便比较、文档链接跳转导航，是装作没看到吗？而且装个翻译插件，还能直接翻译英文文档。


> 大 JB 不支持，就傻眼了，只能嘴硬 “自己用不上”，

这该说什么呢？这是为抗而抗吗？ JB 不支持的功能多了去，但 JB 系难道也不支持你去扩展？不支持你去写插件？我寻思写个插件也没什么难度啊，不想写插件，就用 groovy script ，直接 Java API 操作 IDE 。我们自己就开发了很多 JB 插件，从部署、调试、汇编等等。

> 远程编辑
> 在外网上百台服务器里跳来跳去，每台有需求就弄一下

这个只能说勇士，直接去改生产环境。几百个服务器你去 vim 几百次？

有没有一种可能，可以不用 Gateway ，JB 里面配置 Deployment 到测试 /开发环境，远程改好后再发布到生产环境？

都 2202 年了，裸奔上生产环境改代码的事还是少搞为妙，开发些工具或者使用成熟工具，大家都图个安心。

[liuxu]

楼上的几个小兄弟都没有信仰，要不还是去打 dota 吧，跟我来一起打永劫无间也行

[ColorfulBoar]

@ffire #93 我在那一层不是说了么，inline 那么用 100%是对语言关键字理解有错，没有什么争议。剩下的都是 OP 实际上在写 C with class 而不是 C++的标志，不是说绝对不能用，但这种东西满天飞的代码基本上只用了 1%的 C++特性，这上面 vim 能用是绝对证明不了在其他 C++特性用的多的项目上 vim 能用的。这就像是…如果一个 TypeScript 的环境只对一堆 anyscript 代码测试过，能证明这玩意「能用」吗？
另外这整个楼和我说的这些相关的历史是这样的，最开始有个人说类型推导等东西 vim 估计干不了，然后这个时候 OP 如果直接承认自己平时就不用 auto 等涉及类型推导的东西所以不知道能不能用，那我绝对一个字都懒得打，毕竟不用什么或者不知道什么都很正常。结果 OP 在主楼贴了个 int x =1; auto y = x;来「证明」 vim 下面能正常看到 auto 类型推导的结果……这就相当于有人说 C++编译慢，然后一个人写了个只有一行 int main() {}的 cpp_is_so_fast.cpp 一瞬间就编译完了然后说 C++编译一点都不慢啊，这你让我说什么好？
到这个时候我第一次回复还是只关心 vim 能不能用的，结果 OP 不知道吃错了什么非跟我扯 shared_ptr 觉得我 C++水平有问题，那我只能翻翻他都写了什么神奇代码了，到这个时候我列出来的那些（中的一部分）才成了「问题」，因为我真的看了他写的代码发现并不属于应该用这些特性的情况。所以归根结底，我根本就不关心别人用什么 IDE ，但 OP 非要用这种方式「证明」 vim 上能解决一个自己平时从来不用的特性，然后接着又出来秀自己 C++水平的下限觉得别人菜，这总不能怪我吧？


@liuxu #106 我也觉得有这时间不如开一盘 dota ，所以有什么推荐的新版本整蛊姿势可以让我去坑害队友吗？

[sy20030260]

不否认 Vim 在拓展性上确实有优势，但是很好奇除了自己折腾的场景除外，在真正生产场景中 Vim 的高拓展性到底能发挥多少价值？我是 JB 系重度使用者和 VsCode 轻度使用者，在现实生产场景中用到 JB 的功能甚至都占不到它完整功能集的 20%。JB 的功能已经完全超出我在生产场景中的需求，偶尔一些拓展性借助插件也能实现。我真的不需要那么灵活的拓展性，而且我遇见过的程序员他们大多也不需要

拓展性高，用统一的工具解决所有问题当然很爽，但是为了这种爽付出的代价是：开箱即用的产品体验、易用性更高的图形化界面、商用级别支持的 IDE 配套服务等等。为了多 10% 的高拓展性却要牺牲 90% 常用场景下的产品体验，这个边际成本对于大多数普通用户来说也实在忒高了...

[haoliang]

我看有几位提到了“圣战”，拜托，这啥圣战啊？主角谁呀？我没见 emacs 用户出来说 up 主的知乎回答有啥问题；反倒是几位没深入用过 vim 甚至没入门 vim 的用户来踢馆，我到目前没看到值得“圣战”的点。

我来凭空找几个角度（然而我只是轻度使用 doom emacs ）：vim 的 syntax highlight 全靠 regex 存在不准确的情况、性能不高的情况； cli 下的 vim 受限于 terminal 不能使用所有按键组合、不能显示图片、也没法在 split window 中预览渲染好的 markdown ； lsp 不是内置的，使用上有一定延迟（至于能不能接受偏主观感觉），异构扩展中难免使用 vimscript 专有的 api ，传递、接受变量时有额外的序列化消耗。

跑题一些，接触到用 n/vim 的人中并不只用 n/vim ，都会利用其他工具来扩展自身能力，比如：terminal+floatwin/popup window 配合 fd+rg+fzf 、quickfix/location list 配合 rg 、自身的异步任务系统、自定义 syntax 、ftplugin 配合 git 、等等。

也作为一个 “vim”老用户，我不会只困在 n/vim 中，我当然要关注、使用其他同类工具收获一些灵感以提高**我自己**对于写代码体验上的理解跟需求（没错，需求是被创造出来的）。比如最近我发现 doom emacs 中的 lsp 补全可以做到 fuzzy match ，nvim 的 builtin lsp client 没有，而且受限于 popup menu 的相关实现没有暴露的 api ，我没有找到可能的方法；看到新 pattern ，我在想依照 n/vim 的扩展能力它应该可以为我所用，而且也往往是早就有人想到实现了个插件。

最后提一嘴 ide ，我不喜欢用它的一个原因是，它集成了太多我不想要的功能，长期自定义使用 n/vim 、archlinux 桌面 work flow 的我不太能接受。

[w568w]

产品这东西都是秉持着「哪个好用用哪个」的心态。你觉得 Vim 优美，他觉得 Emacs 强大，我说 JetBrains 、VSCode 牛逼，最后还是要看哪个实际用起来方便。有的人喜欢折腾、高度定制，就有的人喜欢简洁、开箱即用，两者不冲突。

远程编辑配置文件用 Vi/Vim 因为它预装，管理日常纯文本文档用 Emacs 因为有 org-mode ，本地开发用 IDE 因为我不缺这点性能，瘦主机（比如平板、手机）上看别人发来的代码用 VSCode 因为它可扩展性好，还有高亮，而且我没键盘。

我看互联网十几年，把工具关在象牙塔里供着、不允许他人玷污的心态，多半是有点精神偏执问题的；因为用顺手的工具不同而相互攻讦，更是有点大毛病。

你用工具，不是工具用你；信仰用来愉悦自己，不是嘲讽他人。编辑器是这样，操作系统是这样，手机品牌是这样，任何个人喜好更应如是。

[felixcode]

其实楼主的帖子没说 VSCode 或其它 IDE 有什么不好。
但很多人一定要通过抨击 vim 的不好，来显示出自已用的 IDE 多么强大，用自己的方案多么合理。
事实上这些人里，很多人都没试过 vim 哪怕稍微深度一点的配置。
对于未知的事物多一点好奇心与敬畏心，是做技术人应该保有的心态。

[drackzy]

Neovim 的配置照着这个改的，上手比从头配置难度少很多。又加了一大堆星多的支持 LSP 的配色。现在用的Ｗ ezterm 里开个 Neovim 或者 Neovide, GUI 都是 Rust 写的显卡加速渲染丝滑流畅。

[palfortime]

惨了，我是用 vim 写 java 的。crud 工人是不存在重构的。

[akyle]

使用 Vim 写代码，是因为摸鱼时间太充足？

[gbin]

IDE + Vim plugin 才是最终的解决方案。

[FallenMax]

只说个人体验：试过完全用 vim/neovim 开发了几个月，最后还是回到 vscode+vim 插件，原因：

1. 需要花大量精力学习 /配置 /整合 vimscript/lua/ 市面 vim 插件，但最终配出的效果仍然只是成熟 IDE 对应功能的降级版，bug 多，综合体验差（很多是由于插件间互相干涉或互不感知导致，算是没有整体设计导致吧）
2. 插件升级经常出问题，需要跟 readme ，去改配置代码
3. 能映射的快捷键太少（受 terminal 限制）
4. 学习路径不合规律。举例：很多插件上来就要读很长的说明，要了解它如何配置，有哪些 command ，要定义到某些 shortcut 并记住后，才能开始用，起手成本太高。符合正常学习规律的做法应该是像 vscode 这样：下载插件后，扫一眼文档（一般有 gif ）就基本可以用，不记得插件有哪些功能时，用 cmd+p 命令面板搜下这个插件的 command 并执行，用到后面发现确实常用的命令，再去设成快捷键。整个流程没有「一定要记住」否则用不了 X 功能的点。

[pooorguy]

现在 vim/neovim 和 Emacs 成一家，受到 VScode 压力枪口一致对外了嘛，多年在用 vim/neovim ，先说下结论：

我用我可以，你用不推荐。

vim 功能一直很强， 但早期版本和现在版本在插件方面差别已经很大了，早期的插件只是作为 vim 功能的补充，有它锦上添花，没它也能用。而现在插件功能强大到甚至侵蚀并覆盖了编辑器本身功能，比如光标移动插件，不用再 hjklwbe ，比如 tree-sitter ，它的主要功能之一就是代码高亮，在它的默认配置说明中就取消编辑器原有的代码高亮功能，更别说 LSP 这样，总会有人把它从现代编辑器移过来的了。

所以在我看来，vim 和有插件的 vim 是两个编辑器，而安装现代插件的 vim/neovim 和现代编辑器如 vscode 正在逐渐趋同。

最后打一个不恰当的比喻：作为 vimer ，vim/neovim 就像我的结发妻子，一直陪伴在身边，虽然徐娘半老，但风韵犹存，值得牵手走下去，但是 vscoder 们， 想要另寻新欢？ 还是找年轻漂亮的吧～

[murmur]

@drackzy 截图直接劝退，倒了圆角的一个窗口，底下的状态栏四四方方卡在那缺一块，害死强迫症

[L4Linux]

什么扩展啊、功能强大啊，我认为不完全是 VIM 吸引用户的优势。前面很多人也说了，这些优势有待商榷。

但是 IDE 、VSCode 之流做不到但 VIM 能做到的是全程 keyboard driven 啊？有些人就是不喜欢鼠标点点点啊？这个时候你推荐他用 IDE ？用 VSCode ？

[workman2021]

Vim 重构起来不方便吧

[zjsxwc]

拓展插件 还是 emacs 自由一点

[spesun]

个人使用起来感觉 vim 最强的是，在 normal 模式操作时相当于多了很多快捷键，而且很多编辑器、浏览器、文件管理器等都支持按照 vim 的快捷键进行类似操作。学了一次以后，很多地方的基本操作都是通用的。

[james122333]

赞同楼主想法 vim 除了原本的使用方式有看点 扩展也简单且灵活 至于编辑器本身没有的功能可以透过外部程序 快捷键数量也十分多 组合键 连续键都可以 会觉得按键冲突本身就有原因 很多扩充很喜欢用全域变量与全域键盘映射 但是在 vim 下这些都是有作用域的 你可以不同缓冲区不同页签下使用不同的设定 不同模式下也有不同键盘映射 vscode 下 tasks 不用说了 这是很差的作法 换是我直接在项目目录下放一个.vimrc 然后启动的时候最后读取 可以根据项目自定义需要的设定 个人都是这么做 至于代码 format 说实话的 vim 本身都不一定需要提供和实作 因为 vim 可以调用外部命令修改当前文件内容并反馈至屏幕上 至于其他编辑器或 IDE 写扩充的方式不用说了 有人爱写就去写 反正我是受不了一个简单的事情搞得太复杂 markdown 的情况则是规范都没统一 要解决也不是不可以 只要你命令行功底高这都是可以解决的 差别在于技能的不同

[11232as]

@LxExExl 那个是 vim 的 regex,```s/<regex>/<replacement string>/g```是用来替换得,```g/<regex>/d```是用来删除得

[daveh]

@L4Linux #119 你这话 OP 还有那 vim 博主都不敢这样说。

你这是没用过 JB 系甚至 VS Code 吧？ JB 系按双 Shift ，VS Code 按 F1 还是啥来着，直接输入你要执行的操作或功能，回车执行，全过程键盘操作。特别 JB 系，基本每个操作都可以分配快捷键，就怕快捷键不够用，想全程脱离鼠标完全没问题。

[james122333]

@daveh
组合键不高效 F1~12 距离长 而且考虑到一个快捷多种行为会更低效 甚至我连设定都不想用鼠标

[daveh]

@james122333 不知道你想说什么？
这样吧，你理解 JB 系的双 Shift 、还有双 Ctrl ，以及 VS Code 的 F1 ，就是 vim 的 ESC : 命令行模式好了。

[monetto]

@daveh 支持。

说实话，我还是不理解，为什么我在 JB 里面，一眼就能看明白的，满足我 90% 使用场景的事，放着不用，我要去 Vim 里面花大把大把的时间去学习配置和学习概念，用大量大时间堆砌一个能满足我 95% 使用场景的工具？我是多跟自己想不开...

[james122333]

@daveh

我指的是你指定其他动作(如开启档案等一些基本操作)是否也要用组合键 组合键与 F1~F12 本身就不高效 然后绑定一个快捷运行连续行为更是麻烦(这是脚本好处) 然后最后指的连设置都不想用鼠标对应你回应的"全程 keyboard driven"
快速启动与 vim 下的命令行模式差非常多... vim 下命令行模式可以指定变量、键盘映射、呼叫命令函数甚至直接执行 vimscript 逻辑 而且都是内建直接呼叫就好 你 run groovy script 可以实现非常多 但就不是内建而且你总要先经过设置这一关 还是得用鼠标

[james122333]

当然纯 keyboard driven 可以 但我相信没人想先 alt+x 启动选单一直按 tab 跳转来设定
或者直接写 xml 设定 完全就是悲剧

[james122333]

如果都没 vim 插件 纯用 run 光 vim 下常规操作都够呛...

[XIVN1987]

@drackzy

这个视频里作者写配置文件的时候都没有补全提示，，vscode 里面配置文件是有自动补全的。。

[daveh]

@james122333 你还是打一下标点符号，要不看不大明白，看起来也比较累。
VS Code 我不用不好回答它的 F1 有什么功能。
但 JB 系的双 Shift ，名称虽叫 Search Everywhere ，实际上不仅仅是搜索，其功能也是非常强大的，你的疑问建议有条件自己试试。
前面说过 IDE 的所有操作，基本上可以用这个入口键盘操作完成，包括你说的打开文件，以及各种动作。并不一定需要去绑定快捷键，当然快捷键也是一个很好的方式，你甚至可以通过这个入口去绑定快捷键。
IDE 的设置也可以通过这个入口去完成，并不是你想象的要用鼠标去改设置，常用设置输入名称，选中回车即可，需要查找设置用 / 开头搜索各种设置，改键盘映射什么的都行。
甚至它还带一个简单的计算器，直接输入算式它给你出结果，说明其扩展性也非常强，有什么其他诉求自己写插件就行。我不清楚为什么有人要这样去执行脚本，或者用什么变量、函数，如果有这样诉求但官方不支持，写个插件增加一种 Search 类型去处理脚本不是难事。

[james122333]

@daveh

测了一下双 ctrl 跟双 shift 是不同东西 但这东西是半残的 稍微方便一点 但离方便自定义快捷还有一堆设定是不行的 我依旧要按个老半天 还要随时从中间打字区换成方向键 搭配 ctrl/shift/alt/f1~f12 键本身就不是很好用 计算机那更不用说了 这 vim 本来就可以做了 还可以做的更多 大家都知道插件可以... 重点是插件怎么来的... 会写 intellij 或 vscode 插件的人本来就不多 相较之下 vim 容易多了 这正是楼主强调的 甚至不需要高深编程经验就可以自定义

[daveh]

@james122333 呵呵，好吧，算了吧，没看懂你想做什么？你不想方向键你把文字输完整不就行了？你用 vim 难道还不用输入文字？我寻思你用 vim 输入命令也不用方向键吗？不想用 ctrl/shift/alt/f1~f12 就别用快捷键呀，这都是个什么问题？都矫情成这样了。
懂 JVM 类语言的人都可以很快写插件，不懂的人直接下别人做好的插件，需要什么高深的编程经验呢？
倒是 vimscript ，也是一门不太流行的编程语言，想写好又没有很好调测手段，需要的技能非常高。

[james122333]

@daveh

方向键是选择细项 当然各种操作都会用到 频率太高 输入命令补全就好不用方向键 intellij 预设能让你选择不要用组合键和鼠标吗 这是实话不矫情 写插件都需要该应用的知识不只 jvm. 就是有功能需要才看重简易扩展 已有的本身就不是万灵丹 所以这里一直都有月经帖
难道还要向插件开发大佬跪求插件... vim 本

[james122333]

vim 本身就不是没门槛。 脚本也确实没那么多人用 但相对于其它语言是易用的 本身文档也充足 还有一些网路文章。正适合楼主和类似我的人

[L4Linux]

@daveh 我从来没按过方向键以及 home 这一类的键。Fn 只在切 TTY 和 BIOS 里设置好的调整屏幕亮度之类的时候才按。

IDE 和 VS Code 就别来碰全键盘操作这个瓷了，你让 JB 把所有快捷键都绑上啊？小心别和你的图形环境冲突了。

[skywind3000]

@ColorfulBoar 70 楼，不要出来丢人了。

计算机分支技术那么多，从来没见过哪个领域，像某些 C 艹 er 一样喜欢卖弄的，急着想给人当老师的。看了下你的回答，说你是语言律师都高抬你了，比你有水平十倍的人都不会像你这么爱卖弄。

## 指针

> 居然还指着一个内部 private/protected/public 乱飞还藏着个 virtual destructor 的 class 讨论跨二进制

我好心提醒你 xxx_ptr 跨二进制要挂，你来跟我说我写的 BasicBitmap.cpp 不能跨二进制，合着我哪句话跟你说过，我说了句 “跨二进制” 那么我所有类都要跨二进制了？你脑袋是不是进水了才会理解成这样？

BasicBitmap 本来就不是为了跨二进制实现的，天生就是为了继承设计的，它后面可以继承 GdiBitmap, GdiPlusBitmap, DDrawBitmap ，提供出不同风格的 Bitmap 来，

> 行还是回去复习一下 COM 是怎么搞的吧，Essential COM 第一章就行

COM 里不就是依靠 Release 代替析构保护跨二进制不同堆的析构释放冲突问题么，老衲二十多年前写 COM 时看一眼就明白了，用得你来教？你哪年学会的 COM ？写过多少 COM 相关代码啊？

> 裸指针手动释放配合多个退出路径是件多么可怕的事情，在 goto 和 goto 到的进行集中错误处理的地方中间会发生什么可怕的事情

现代程序，内存分配失败就应该 assert 了，还 goto 多路径释放啊？即便要处理，也只是构造和析构里刻意注意下罢了，这种你都写不来么？

> 它最后（在你不手动塞进去奇怪的 deleter 的时候）生成的代码真的和裸指针有区别吗（当然前提是后者用对了并确实持有所有权）。

生成代码是一致的，但是我也不想到处用，为啥？根本不是性能问题，有些人干什么事情都爱带套，明明就是只有这个类用的资源，构造里产生，析构里删除，你觉得非要套个 unique_ptr 的套套你才舒服，我也没说你不对，但是干什么事情都头上都要顶个套套，更多人会觉得浑身不自在，就像明明没下雨，有个二百五非要穿一件雨衣在操场上跑步一样，凡事有利有弊，到不说说不能跑，只是觉得这么搞有点二，有点书呆子的感觉。

> 再思考一下什么人会在别人指着拿指针传进去的字符串的时候第一个反应不是证明这里不适合用(w)string_view 。

你以为代码只在你一人的机器上编译吗？有些象牙塔里 C 艹 er 就是喜欢对着新标准就高潮，从来没考虑过客户的编译环境，因为他们很少做真实交付的项目，不是说新标准不好，string_vew 的 17 标准里也有我想用的东西，比如 if constexpr ，可以让我的代码编译期做判断提升性能，但是我忍住没用了，改用模板和宏去模拟，为啥？

不是迫不得已非必要不升级，我想尽量维持 14 以下的标准，因为 PyStand 本来就是辅助 Python 部署的一套库，我希望用我项目开发的人至少可以在 xp 下发布他们软件，并且大概率手上的编译器都可以编译。

这些工程领域的侧重和思考，真的不是某些甚至校园都没出过，正儿八经的项目都没做过几个小儿能理解的啊。

再，即便 14 里有 string_view ，我也不想用，string_view 这种东西我看不上眼，正式项目里我用自己仿照 Qt 实现的 QString ，std::string / string_view 这种东西同 if constexpr 不是一回事情，我真看不上，QString 有多强，你可以学习下：

https://www.zhihu.com/question/54664311/answer/140476787

大道至简，这个 PyStand.cpp 很简单，我不想引入太多依赖，这么简单的代码，这么简单的指针用法你都 hold 不住，非要带一个 string_view 的套套，当我没说。

> 另外正常人也别写这种 string 转 wstring 都能搞得一坨 magic number 乱飞的代码，不会转可以塞进 std::filesystem::path 让它自己转

又来，我跟你说了我希望尽量限制标准在 14 及以下，你完全 get 不到我的角度。

有一种虫，春天出生，到了夏天就死掉了，你跟它说冰是怎么一回事情，它是永远不可能明白的，所以叫 “夏虫不可语冰”，我觉得写代码让更广泛的编译器支持我的代码的意义，比只知道无脑飙 C++ 版本更有意义。算了，没做过啥真实交付项目的人，说一百遍他都领会不到。

> C 风格指针恶心人的程度已经是罄竹难书了，这连一半都不到

觉得恶心的话你去跟标委会那帮子鸟人提案，让他们把指针从 C 艹 下个版本里删掉啊，我乐见其成，看看他们听你的不。

有些 C 艹 er ，成天听到的名词不少，可实际深入点的经验全无，拜托你读两个真的工程上大量使用的项目代码再来这瞎 BB ，计算机领域很多，别总在你熟悉的那个领域里打转，真实的世界永远不是象牙塔那么的简单和纯粹。

## inline

> 如果后面的读者不想变得这么搞笑：inline 是让你处理 one-definition rule 的，或者再简化一点，inline 的意思是「你可以就把定义写在这」永远忘了内联优化这回事

所以说你从来只看得到一，看不到二三四。BasicBitmap 里，老衲前面已经给 inline `#define` 成具有 always_inline 属性的宏了，你是眼睛瞎了看不见，还是不知道什么叫做 always inline / force inline 啊？

## 底层

> 自行搜索 abstract machine 找个 talk 听一下 ... 还做着自己真的控制了编译出来的汇编的春秋大梦呢（顺便这种人恐怕一半不知道 CPU 上最后执行的不是一条条的汇编指令），实在不信找份 C++98 的文档（我感觉 C89 都行），搜一下 volatile 是干嘛用的。

计算机分支技术那么多，从来没见过哪个领域，像某些 C 艹 er 一样喜欢卖弄的，喜欢好为人师的，volatile 我二十多年前的代码里就有了，要你教么？

程序员别成天只知道代码，别满脑袋都是技术，走向社会要吃亏的，有空多了解下技术以为的人文知识，荀子曾说：“故不问而告谓之傲，问一而告二谓之囋。傲、非也，囋、非也；君子如向矣。”，看不懂的话我给你翻译一下，荀子他老人家说：“别人没有问就去告诉的，叫做急躁，别人问一个问题而告诉别人两个问题的，就叫做唠叨”。

动不动就 “你看看 A 去”，“你知道 B 吗？”，生怕别人不知道他懂一般，在荀子口中都是君子为人需要避免的东西，计算机领域博大精深，谁都有不知道的东西，动不动就想教别人一下，在你小圈子里没问题，出了圈还这么着，不能教而强教，担心闹笑话。

> 顺便看一眼 strict aliasing rule ，懒得搜可以直接读 https://www.ralfj.de/blog/2018/07/24/pointers-and-bytes.html 这个系列，再看看 C 语言大师们起手-fno-strict-aliasing 然后觉得自己特懂底层。

拉倒吧，就你懂，别人都不懂，得了吧？ strict aliasing 鬼东西，我几年前就喷过了：

https://www.zhihu.com/question/19707376/answer/1174526354

上面那个 volatile 是合理的，因为编译器做优化时无从得知是否有另一个线程在访问同一个变量，因此如果计算的结果出于优化目的暂时不落内存而呆在寄存器里，那么另一个线程就无从得到最新值了，这是非常合理的设计。

但是 strict aliasing 这种傻鸟设计的东西不一样，这属于当年标委会那帮子鸟人设计出来的缺陷东西，全部遵守的话，全部遵守的话，让那帮象牙塔里的人来用当年的标准（不用 bit_cast 这些 20 里打补丁做裱糊的东西），他们都很难写出正确的 memcpy ，这不搞笑么？

所以不管 vc, clang 这些广经实践检验的编译器知道对这条要留神处理，gcc 早年版本也还好，只有最近几年的版本不知道是不是眼红 java/clang 的优化牛逼，自己又没本事进一步优化，才会这么丧心病狂的拿着这条标准里的鸡毛蒜皮出来最大化的恶心人。

语言设计要为实践服务，不用反过来，标准也不用跪舔，有缺陷就要承认，手动加 `-fno-strict-aliasing` 就是要帮那群鸟人做一个生理上的结扎，让他们不要出来祸害人间。你这么看不上 `-fno-strict-aliasing` 的话，把你电脑里所有用到这个的项目干掉，你看看你电脑还能不能启动。

## bonus

> 我看到图形引擎四个字终于想起来了……后面的人请打开 。。。跳到 DirectX 那一节，啊 2015 年……彼时 Metal 、DX12 、Vulkan 这一批现代图形 API 都已现世，早就翻来覆去讲清楚了传统状态机式图形 API 是一件多么恶心人的事情，在这个时间点居然能舔得下去 OpenGL……我已经说不出来话了，哪位心理学大师能帮我分析一下为什么一个这么热爱《底层》《精细控制》的人能喜欢上 OpenGL 。

拿着我一篇 2015 年写的旧文说我不懂 2015 年刚出的 Vulkan ，合着你 2015 年就用 Vulkan 写过程序？那我拜服你了，vulkan sdk 1.0 直到 2016 年才发布，你真牛逼。

象牙塔里的人就是这样，听过的名词一大堆，现实的项目没碰过，说起图形能谈论的就是几个 API 名称，除了这些大名字你还能谈论啥呢？

你只有本事把评论区六年前和我抬杆的人的 "状态机" 拷贝下来和我说，任何 API 都有不完美的地方，状态机是 OpenGL 不完美的地方，但是编程里不是没法处理的，事实上游戏和图形里的 render states 一般都比较稳定，同一批次的渲染指令一般都用类似的 states 执行，程序稍微注意下是很容易处理的，不是什么过不去的砍，后面新的渲染技术诸如延迟渲染和 shadow map 这些需要多个 pass 的，会频繁大量的切换渲染状态，2D 界面和 3D 物体的渲染也会大规模状态切换，这时，不管 Dx 还是 OGL 都有对应 API 来一次性保存和恢复 render state ，大部分引擎都会有一个 render context 的封装类，来处理这些大规模状态切换。

至于我不喜欢 DirectX 喜欢 OpenGL 的原因前面我也给出理由来了，D3D8 以前，DX 基本上是被 OpenGL 按在地下吊打的，D3D7 有时甚至做不到精确渲染，但是 OpenGL 没问题，可是微软出于商业目的故意打压限制 Windows 下的 OpenGL 发展，这个事情恶心到我了，尽管后来 DX9 开始做的不错。

## ？

> C++当然不止一种写法，但所有主动写 C with class 的 100%连基本的东西都没弄懂，永远在传播错误的认识。

不要生活在真空世界里了，C++ 比你厉害十倍的人我也经常和他们交流，真的懂 C++ 的根本不会像你这么阳春白雪。

你所想要消除指针的想法很美好，标准更迭那么多年了，年年有人骂指针，又没本事把指针从新标准里删除，所以如果你一定追求，大可以换个语言，不用写 C++。

某个领域的成功经验，换个领域就完全不适应了，而大部分人却只会把自己特地环境里成功的经验总结成万古不变的真理，进而在环境改变后碰到挫折还不能自知。

比如 GUI 领域的著名项目，Qt / wxwidgets ，看看他们是不是指针到处飞？语言领域的 v8 里面是不是到处飞指针？音视频领域的 webrtc/srs 这些是不是到处飞指针？只有局部地方才会有限制的用一下 xxx_ptr ，图形领域的各种 3D/2D 引擎 Ogre3D / Unreal / urho3d 哪个不是飞指针？他们不懂引用计数？他们懂啊，局部用，用也是用自己实现的，看不上你 std::xxx_ptr 。

系统开发领域唯一的 C++ 内核 Fuchsia ，它是用了 std::shared_ptr ，但是用的也是非常节制和有限，大部分地方还不是在飞指针。

为啥？就是你一直在笑话的“精确控制”，你但凡读一两个上面这类各个领域的著名项目，你都不会这么肤浅的尬笑了。你觉得飞指针就代表没有生命期和所有权管理么？非也，给个项目都有明确的所有权和生命周期的管理方法。

实在没时间读上面的代码也没关系，Qt 解释过自己为啥用裸指针，以及他的所有权管理：

https://doc.qt.io/qt-5/objecttrees.html

Rust 程序员给 qt 做 port 的时候都能意识到：

> Qt has its own ownership system that must be respected

连天天把所有权视作生命的 rust 程序员都能 respect ，不明白你个 C 艹 er 在这里一副要秒天秒地秒空气的样子干嘛？

工作上 C 艹 写的比你牛逼的人多的是，我很尊敬他们的，他们有学术素养又有成熟的工程意识，还能平实的和人讨论问题，可他们没有一个像你这样摇里晃荡的摆来摆去，像孔雀开屏一般，生怕别人不知道你有几斤几两。

[skywind3000]

@felixcode

> 其实楼主的帖子没说 VSCode 或其它 IDE 有什么不好。
> 但很多人一定要通过抨击 vim 的不好，来显示出自已用的 IDE 多么强大，用自己的方案多么合理。

是这么回事情，我向来只见过 vimer 们安安静静的在自己的板块下交流心得，从来没见过哪个 vimer 跑到大 JB 或者其他 IDE 板块下面去劝退，反倒是大 JB 和其他 IDE 的人按耐不住，经常跑了 vim 板块里踢馆，来说 Vim 都是垃圾。

他们的大 JB 和 IDE 那么好，自己用得爽不就行了，经常跑来 vim 板块里气急败坏的闹事和劝退为个啥？

[skywind3000]

@daveh 你喷了 vim 一半天也没喷到点上，看看 109 楼是怎么喷的，那才叫专业喷法，可以学习一下。

[skywind3000]

@haoliang 大部分认同。

> cli 下的 vim 受限于 terminal 不能使用所有按键组合、不能显示图片、也没法在 split window 中预览渲染好的 markdown

后面都是对的，就是个不能显示图形和不同字体的问题。至于第一条 “不能使用所有按键组合” 是不对的，Vim 提供灵活的机制让你定义每个组合键的键盘码，大部分人不会初始化而已：

https://github.com/skywind3000/vim/blob/master/plugin/altmeta.vim

showkey -a 看看键盘码，然后像我上面这样设置一下就行，这样的设置允许你设置任何组合。

Vim 8.2 还引入了 modifyOtherKeys 的特性，只要终端支持，任何组合键都没问题。

[daveh]

@L4Linux 都说了绑快捷键是可选的，JB 中你完全可以双 Shift 输入去完成任何操作，全键盘操作不是问题。
甚至 JB 系，你还可以安装 ideavim 插件，模拟 vim 的使用，用上 vim 类似的全键盘操作。ideavim 是 JB 官方出品，比 VS Code 的网友作品 vim 插件好太多，完成度已经比较高了，还支持部分 vim 插件，甚至还支持 vimscript 。ideavim 是开源的，还没完成的功能可以自己提 PR ，这才是显真水平。

另外 Fn 是 VS Code 的，不是 JB 系的。

[zhouwb]

我靠，这么热闹吗？其实楼主没必要跟别人掰扯这个事，我没用过 vim ，不过 vim 对于半专业人士或者初学者的确不友好，这是真的，但是 vim 功能强大扩展性超强也是真的，其实就是每个人的习惯或者思维方式不同而已，我老婆还觉得我的 mac 电脑超级难用呢，我身边朋友觉得 360 浏览器比谷歌浏览器好用，你要怎么说服她呢？其实没必要，为啥要说服他，你和与你志同道合的人觉得好就行了

[L4Linux]

@daveh 可是全键盘操作不是为了全键盘而全键盘啊？各种 VIM 插件不也就是编辑的时候模拟一下？离 keyboard driven 差远了。

[daveh]

@skywind3000 @felixcode
#111 #140

你们这回复有点搞，什么时候中文退化成要说“不好”才意思是真的不好？
你看那 vim 文的作者，从其他 IDE 抄袭了一些特性，先不管像不像，就不得了了，好像 vim 无所不能似的，对其他 IDE 不屑一顾，甚至还曲解了有些 IDE 功能。
而现代 IDE ，本身就是一个强大的编辑器，加上商业把持，有些地方已经做的非常完善了。
说句不好听的话，vim 你再怎么配置，山鸡就是山鸡，不会因为你插了几根羽毛就变成凤凰。
当然我说这话难听了点，但这是事实，这也不代表我不用 vim ，偶尔简单任务也可以用用。就像回帖里面有些人故作中立一样，“哪个好用用哪个”，但真的是吗？就一些高级功能或者便利性来说，商业 IDE 完全是碾压式的，你不用你就效率低。
前面说道“未知的事物”，我倒是觉得，可能由于商业 IDE 收费原因，对很多 vimer 来说可能是未知事物，接触不到最新 IDE 技术前沿，真的，不要固步自封，连 LSP 都不是 vim 发明的。所以我建议有条件 vimer 多去用用其他 IDE ，上面回帖，也给了很多场景下用 vim 和 IDE 的使用比较，有时候方便不止一点。真熟悉或怀念 vim ，安装一个 ideavim 插件，插件完成度很高了，有能力的可以去把插件功能补全，或者移植 vim 插件给 ideavim 用。洋为中用，这样才能获得更高效率。

OP 讲什么 vimer 们安安静静不踢馆，再说句难听的，你们真没这个实力去踢。你要来踢馆先得熟悉其他 IDE 使用吧，等熟悉之后说不定就跑路了，少部分死忠 vimer 学会了一些 IDE 技巧，费劲移植到 vim 中用，然后欢呼我大清朝养的汗血宝马，跑赢洋鬼子的火车了！
讲真，真正的 vim 社区并不是那么封闭，像 LSP 这种新鲜事物都能接受。反而是一些“死忠”vimer 像大清朝的遗老遗少一样，接受不了别人推荐的新鲜事物，别人给他做个 IDE 比较，他就玻璃心了，在他眼里就成就成闹事、劝退、喷子了。真的，你们不代表 vim 社区。而且我们也不是来踢馆的，只是做个比较与功能普及。凤凰是不会特意来和山鸡比较什么。

[wzzyj8]

@bwangel 有没有可能这点小问题 Neovim+Coc 就能很轻松的解决

[maguowei]

都 2022 年了 云 + 容器化 + terraform + vscode remote 配合线上 cicd ，已经让 vim 在服务器端的优势越来越低了。而本地端各种 IDE 在 80%的功能上都可以秒 vim, vim 的扩展性和复杂性是双刃剑，门槛太高，注定绝大部份人使用它都是轻量编辑。

我对于 vim 高手确实是心怀仰慕，但是这改变不了历史趋势。

[ixx]

这么多年了 没想到编辑器引战能力一点没减 😂

[libook]

坐等 Emacs 骑士出战 [狗头]

想分享是很好的，可以把自己收藏的好方案、好思路分享出来，让有需要或感兴趣的人可以有所启发。但强行推荐和捧一踩一实属踩了互联网大忌，意味着一定会招来论战。

文本编辑器就不要强行跟商业 IDE 比了，很多 VS Code 党炫耀优越感的时候我也是这么说的，知道 Vim 很能装插件，但 JB 的代码分析能力是非常对得起它的价格的，一个是灵活性高的开放平台，另一个是花钱即可开箱即用的生产力工具，根本就不是竞争关系（全都要岂不更好）。

我个人也喜欢用 Vim ，但我很清楚什么场景下对我来说选什么工具最合适（所以我 Vim 、VS Code 、IntelliJ Ultimate 都用），而不是强行让自己在任何场景下都坚持用同一种工具，除非心血来潮就是想折腾一下。

最后，每个人的喜好、习惯、工作场景都不一样，选择趁手的家伙就好，技术人员的高尚是在于能解决问题，而不是用了啥工具。

[360dust]

请教一个问题，vi 和 vim 是一回事吗？

[bwangel]

@wzzyj8

你这样子讲话，很让人讨厌。完全没有想和你聊天的兴趣了。

[daveh]

@libook #150

你这讲的看似有理，实际上有点幼稚了。
确实你讲的没错，两个没有可比性，但凡事都是要有碰撞，才会有进步，真拿来一起比比，识别别人长处和自己短处，也没有什么问题，死不了个人。不像大清帝国，大刀长矛也用得很爽，但见不得别人夸洋枪洋炮厉害，这种故步自封最终是会死人的。
而真正识货的 vimer 也会去尝试不同 IDE ，选择趁手的家伙。但就是有那么些号称“死忠”vimer ，认为什么都是 vim 搞定，见不得别人优势。你给他讲讲其他 IDE 很强，他就像听人说洋枪洋炮厉害一样，一下子就过度反应。这种就是要用这种碰撞来打他脸。就是要这种强行推荐，你爱用不用，大家都成年人，没法去照顾那些玻璃心。要不 vimer 社区也会像大清帝国，死气沉沉。

[alexsunxl]

emacs 党路过。只能说感恩 treesitter 和 lsp 。
不争论。 哈哈哈哈

[alexsunxl]

@360dust nvim （ neovim ）, vim, vi 就是一个派系里不同的山头。
vim 觉得 vi 不太行，重新起了一个，但是完全兼容 vi ，有增强
nvim 觉得 vim 不太行，重新起了一个，兼容部分的 vimscript ，新增 lua 和各种特性。

vim 完全打赢了 vi ，只有少数老旧的发行版预装 vi ，新的发行版如果有预装基本预装的都是 vim 。
nvim 和 vim 目前还在打着。

[james122333]

@L4Linux

那就是个半残的使用方式 包括他讲的 ideavim 都是半残 这样使用 ide 相对于鼠标并不会快多少 groovy script 也没看到东西

[james122333]

@maguowei

基本上 ide 的功能核心就那几项 从以前 eclipse 到现在 intellij 看到的套路都差不多
也都不难实现 原有的工具一凑就凑出来了 vim 有门槛但门槛不是太高 讲究开箱即用那就没办法了 还不只编辑器 很多东西都是这样 当然 vim 内建东西很多 不用其实蛮可惜的 可以当很多 tui 应用 ide 、股票操作、密码管理、版控工具、数据库客户端都可以 vscode remote 的也不是什么高大上工具...

[TWorldIsNButThis]

@james122333 为什么不用 ideavim ？完全可以映射各种 ide 的 action
而且现在的 ideavim 也部分支持 vimscript

[james122333]

@TWorldIsNButThis

已经在用了 在公司用 基本上就是在公司用 idea/vscode 在家用 vim 原因很多 在家是不会考虑用 idea/vscode 的 大砲打小鸟的感觉 然后这大砲占用空间还很大...
在公司生产力不一定得完美

[james122333]

@TWorldIsNButThis

然后如上所说 ideavim 是半残的

[pisc]

@FrankHB

[24bit]

我 IDE 、Emacs 和 Vim 都用：
- IDE 省心，功能全，在特定语言特定项目这个维度，用 IDE 心智负担会低很多，毕竟别人是靠这个赚钱的，喜欢 Emacs/Vim ，搞个 Keymap 也大差不差
- Emacs 现在我主要就用 Org Mode 和 Magit ，然后还有其他一些临时编辑、文件管理啥的，整体是脱离项目这个单位，面向全局。IDE 打开一个项目还是会占用一定的资源，启动也慢，这时 Emacs 就很舒服
- Vim 就只在终端用了，比如 cd 到某个目录后想简单编辑下某个文件、服务器上需要编辑配置等。所以我需要 Vim 的配置足够小，启动速度足够快。

对于编辑器来说，配置越重，功能越强大，启动也越慢，这个时候和 IDE 比资源占用上也没多少优势了，还不一定有 IDE 好用。

在我看来 Emacs/Vim 的优势首先在设计哲学上，然后才是扩展性。

Emacs 自底向上的设计，所有的功能都可以绑定在一个 key sequence 上，不同的 mode 可以有自己很独特的设计，org mode 在 emacs 中就能自成体系，其他的编辑器中的移植很多时候还是差强人意。

而 Vim 的 Modal Edit 是比 Vim 本身适用范围更广的东西，也许你没用 Vim ，但很多时候也会间接用到 Vim 的部分快捷键或者 Modal Edit 。

而独特的设计意味着就算能在其他编辑器 /IDE 中复刻一部分功能，但也还是没有在原生环境中舒服，这时，在 Emacs/Vim 能满足需求的情况下，我会更愿意用 Emacs 和 Vim 。

而 IDE 就很直接，简单，大而全，扩展性受限，但大部分功能都有了，用就完事。

[CodingNaux]

爱用啥用啥...
想想我这种菜鸡也只能在这种帖子下回复回复了 = =

[maguowei]

@james122333 这里我倒是觉得功能不是重点，eclipse 比 idea 系列差的难道是少什么功能么？ 功能凑出来不难，但要实现 IDE 我自己感觉还是体验

[daveh]

@james122333 什么叫“半残”呢？别人给你一把枪，你非要用做大刀去砍，然后还嫌砍得不够锋利。
对你这种，前面也说很清楚了，嫌功能不全，fork 一个自己去改： https://github.com/JetBrains/ideavim
这不比写脚本高大上多了？写得好还可以提 PR ，这开源贡献不比折腾 vim 大多了？
你想给你的枪，装个多锋利大刀都行。

[kevinhwang]

这个话题过了好几天了，没想到还有热度。
@daveh 别这么极端好不好，作为 idea 和 neovim 用户我想我理解你，但各有优劣。用着商业软件还自带干粮这点我真的没办法理解。除了商业语言例如 jvm 之类的，neovim 大部分都可以胜任(接近于 vscode)，因为引入 lsp 之后编辑器只会同质化，目前 neovim + coc.nvim 已经很接近 vscode 。

我是从 2019 年开始认真尝试 neovim+coc.nvim 的，之前在没有 lsp 的情况下尝试过 vim ，觉得很垃圾，连跟 idea 提脚都不配，但 neovim+coc.nvim 让我改观了，当初在写代码方面能有 vscode70%左右体验，后面 nvim 退出 treesitter 和 lua （我真的不喜欢 vimscript ），简直就上头了，写了不少插件。你所说的内嵌语言 injection 目前 treesitter 是可以实现的，写前端还是很舒服。

不要总看到当下 idea 的优点，要是真的完美就不用推出 fleet 这种“消费降级”的产品。个人预言 ide 对于简单语言将会全线溃败，vscode 这种级别的编辑器是为了的首选，应该是前端标配。

安利自己的插件：
https://github.com/kevinhwang91/nvim-hlslens
https://github.com/kevinhwang91/nvim-bqf
https://github.com/kevinhwang91/nvim-ufo

[zoharSoul]

@kevinhwang #166

neovim 怎么运行 spring boot 和 debug 啊? 求问
就 idea 那种

[kevinhwang]

@zoharSoul 用 idea 。不要在 neovim 用 jvm 语言。
1. jar
2. *.class
3. jvm 语言喜欢架构和套娃，这点 ide 处理起来还是不错的，编辑器吃力

[zoharSoul]

@kevinhwang #168 明白了...
因为我看你提到了 idea... 我以为你用的是 java. 所以请教了一下. 毕竟 idea 是 java 专属的嘛.

[cnbatch]

@360dust 严格来讲不是一回事。vim 是 vi 的增强版。

只不过大多数 Linux 发行版为了省事，直接就自带了 vim 取代 vi ，不用额外再手动安装 vim 。

而在 BSD ，两者仍然分得很清楚，系统默认自带 vi ，想要用 vim 那就自己安装。

[kevinhwang]

@zoharSoul 感觉目前 jb 的是靠 idea 社区版引流的从而盈利，但社区版其实足够开发 java 。我的策略是白嫖 jb ，没必要在 neovim 浪费时间去针对 jb 的强项。java 的 lsp 太垃圾了，套娃框架学习的时候需要一个断点 debug 追踪，这些不是 print log 能解决的。

[zoharSoul]

@kevinhwang #171 嗯嗯, 有道理.

我是看楼主信誓旦旦战了好多楼, 所以出于好奇尝试配置了一下....

[e7]

其它的不说，把 c++用成带 class 的 c 是没毛病的，特性摆在那不用是你的自由，只要能保证代码质量，保证团队其他人也遵守相同的原则

[james122333]

@maguowei

所以愈来愈多人跳到 idea 但其实功能差不多 搞 vim 更不用说了 肯定会整自己的体验好

[james122333]

@daveh

功能不全是半残 ide 还功能不全是致命的
如果有兴趣 会 fork 或提 issue 或 pull request
不过没兴趣 写脚本好多了 因为方便 装锋利大刀都可以
vim 本来就是搞个性化配置与个性化功能的 至于配置与功能高不高看人

[daveh]

@kevinhwang 怎么说好呢？要我说你这理解才是极端。我用商业软件，解决了以前很多开发过程中痛点问题，针对 vim 的场景，介绍了一下 JB 的玩法，码这么多字共享经验，结果却被 vim 社区某些人攻击，我都没说他们极端，到你这怎么就成极端自带干粮了？
你觉得 neovim + coc.nvim 已经很接近 vscode ，但 vscode 离 JB 都还差一大截距离呢。
你在 neovim 能支持内嵌语言挺好，虽然我不知道你支持到了什么程度，但是其他功能呢，比如前面介绍的重构改函数参数，你是怎么改的？
另外我介绍 JB ，也没夸它完美呀，要是以后出来个新的 IDE 比如叫 SB ，比 JB 更好用，我也会来个使用场景比较，推荐大家去用 SB 。

[wenbinwu]

新手来说，现在的 IDE 功能太多了，特别是 java 这样的语言，直接 IDE ，不要去配置 vim 了，不值得

除非你是 vim 摸爬滚打好多年，团队里也都是 vim 党，语言相对简单，你只需要写简单代码，做简单的跳转，不用大量重构，那可以把 vim 当 ide 使

vim 党下一步就会往全键盘，不碰鼠标党靠，效率是一码事，更多的就是自我追求，没事装个逼

[daveh]

@james122333 用脚本就别吹了吧，特别是 vim 这种，要不怎么出来个 neovim 。

[LostPrayers]

我也想试试两只手都在键盘上，不用一会两手，一会一手得去拿鼠标。
但没办法，现在学习 vim 已不太可能，很多操作习惯已经固定了，
换一种操作方式怕是会遇到更多痛点🤣

[DOLLOR]

前端娱乐圈
后端娱乐圈
编辑器娱乐圈

大家谁也别笑谁哈

[realpg]

@daveh #20
VS Code 的界面就是个 chromium 。。。
甚至可以对 VSCODE 的界面 F12

[zbinlin]

我觉得吧，编辑器就做好编辑的功能就可以了，其他的什么语法分析、语法高亮这些应该由 LSP, treesitter 这些来提供。

[jhdxr]

@zbinlin LSP 最大的问题在于性能（这个性能可以指慢、极度吃资源等等问题）

[liuxu]

终于有大佬把 v2 这种刺头风气按在地上摩擦了，靠实力说话，此贴看的我极度舒适 —— 来自 emacs/vscode 用户

[james122333]

@daveh

脚本怎么了... 脚本灵活好写 neovim 都是 lua 习惯哪种脚本就用哪个
vim 也都不阻止你用 lua 、python 当然还有特殊姿势但我不会讲的

[zbinlin]

@jhdxr 你语法分析、语法分析这些本身就很吃资源的呀，换了 IDE 来做也是不可避免的。

[NebulaGraph]

不错，顶 OP 主

[hardwork]

@daveh 看你发言，你根本就不太懂 vim ，真的是在瞎喷，而且一直在瞎踩。

有了 lsp 后，vim 加插件写 rust golang python c 完全不输 ide 了，我觉得上限比 ide 要强。lsp 确实不是 vim 的，但是这正代表 vim 超强的扩展。

[daveh]

@hardwork 呵呵，有条件试试 IDE ，别坐井观天了。

[jhdxr]

@zbinlin 是，但是 IDE 做的话，不会有那么大通讯开销，和可以更好的获取需要 context

[xuboying]

真的大无语，OP 已经把主题发在 VIM 版面了，还有一堆不想用 VIM 的人来 VIM 版秀存在感。我从知乎过来想看看有没有使用技巧，还有 OP 提到的插件的下载地址。大段大段是没有意义的讨论，看对骂真是浪费时间。

这些喷 VIM 的人有没有想过，可能讨论 VIM 的人，用 VSCode 比你溜得多。早就不满足社区的东西自己造 task ，扩展 git lense ，cicd 工具，api check 等等了。

[chemzqm]

鉴于很多人浪费过多时间去配置 vim 并最终放弃使用，我觉得应该有一篇我为什么不建议你用 vim

[FrankHB]

@pisc 这种水平放吱扔过去一坨 nano 怕是都绰绰有余了。

要专业角度评价的话，我只能说：

(1) 我不需要理解非得把大部分日常或者工作时间怼编辑器上的其它专业人群的需求，反正现在和以后我不用这样。
当年我不得不怼编辑器的情况，比如 X51v 铁笔戳上万行代码，要避免浪费生命的限制可是苛刻得多了，这些年来也不大有兴趣再次体验这些问题。（尽管批判 JB 我还是喜闻乐见的。）
(2) Emacs 还有个老不死的 elisp 至少能拿来作为长时间不会过气的反面教材（比如 dynamic scoping 遗老）来批判； VimScript 这种最近还想在大版本号掀什么煋闻的东西，除了煋闻外还真不大想关心。
真要批判“精心设计”过的 DSL ，racket-lang.org 上面一抓一把拎过来不香？

[FrankHB]

@skywind3000 也不是说好为人师，就是看不惯人太菜，还污染环境。
（我才算是发现有人 at 我的用意了。）

0) 你爱怎么写是你的问题，但倒垃圾就是公德问题了。这是常识。

1) 当然菜鸡多的是，人家 STL 说，why is .h ever deprecated ？我还笑话他不懂 deprecated 是 discourage 呢。但是人家也没脸说“我爱怎么写怎么写”啊。

2) 画蛇添足一看就是丈育。废话多，浪费流量和硬盘，看着碍眼，难理解？

3) reinterpret_cast<char16_t*>还是 reinterpret_cast<char32_t*>都不决断的就别口嗨 ABI 了。当然 C 厨嘛，盲猜从不担心 TBAA ，本来还正好省事。
还好意思氵你乎回答大言不惭，谁让你脑补 xxx_ptr 就是 shared_ptr 的？倒是有另外一个跟引用计数没屁股关系的常见的 xxx_ptr 的常见实现还真就有臭名昭著的 ABI 问题，咋不提了？
v8 核心代码里是不是到处指针飞，不碍着它要是不那么辣鸡就更有性价比啊……但是 Google 的那啥 guideline 承认了，他们就缺脑子比较好使能把 C 艹 用对的人，那这现象又有啥不好理解的……

4) 真不想跟小朋友废话……github.com/FrankHB/pl-docs/blob/master/zh-CN/typing-vs-typechecking.md#%E7%B1%BB%E5%9E%8B%E6%AD%A3%E7%A1%AEtype-correctness
（虽然这个倒是真的建议所有人理解。）

5) 懒得看。

@ColorfulBoar 本来就不需要 LSP 啊，什么 LSP ，我就是人肉 LSP （战术后仰
除此以外别的 LSP 顶用？

不过带 template 套不套 inline （就算类定义里）倒是真的不大一样。（大概也就这原因 libstdc++里的类定义里的 template 经常有不省略 inline 的。）
至于代码生成，always_inline+flatten+noinline 明显更顶用点，但是的确有少数就得加上 inline 才会比较不那么欠揍的情况。（比起 github.com/FrankHB/YSLib/blob/master/YFramework/source/NPL/NPLA1Forms.cpp#L2598 或者#L3410 这类抽风当然还是小儿科了。）

[FrankHB]

@skywind3000 139 楼，屎麻烦一次性拉完。

> 我好心提醒你 xxx_ptr 跨二进制要挂

template<typename T>
using observer_ptr<T> = T*; // BS 亲自鼓吹（无误

你家二进制挂了？

另外我算是反应过来也许为啥不提 xxx_ptr 的另外的臭名昭著的二进制问题了，因为那个 xxx_ptr 里有个看起来冗余的设计某种意义就是专治你这种自作聪明的 ABI 小鬼不服的……

> COM 里不就是依靠 Release 代替析构保护跨二进制不同堆的析构释放冲突问题么，老衲二十多年前写 COM 时看一眼就明白了，用得你来教？你哪年学会的 COM ？写过多少 COM 相关代码啊？

所以这就是 COM 严格比这个冗余设计更傻逼的问题了。当然这肯定是故意的，因为 C 没析构这样能特别处理的东西。

也就是这种把 metadata 翻来炒去最后只剩下 ABI ……的哪壶不开提哪壶，要不是兼容 C 的破烂，COM 用起来的体验能那么屎么。人 .NET 为什么没那么拉仇恨？

> 现代程序，内存分配失败就应该 assert 了

Linux kernel：我就乐意超卖给你延迟 OOM 炸妈，不服？还是嫌弃我不是现代程序？

> 生成代码是一致的，但是我也不想到处用，为啥？

怎么就上套了呢。

说了不懂 ABI 欠扁在哪，还硬掰。

> 你觉得非要套个 unique_ptr 的套套你才舒服，我也没说你不对，但是干什么事情都头上都要顶个套套，更多人会觉得浑身不自在，就像明明没下雨，有个二百五非要穿一件雨衣在操场上跑步一样

C 厨的后遗症之一就是看得见 unique_ptr 是个套套，却强行眼瞎到 *（因为欠扁的歧义，我得指出这是个 declarator 里形式上叫做“ptr”的东西，不是 operator ）这个直接写死的垃圾语法和弱鸡语言不是个各种意义上都更严重的套套。
为什么是套套？因为这种东西不配是一种。unique_ptr 好歹允许让用户自己发明其它套套，而削弱了这里的弱鸡程度，反而不具有那么明确的套套属性。
本来更一般意义上，这就是个挂到 parametric polymorphism 上实现的 unary type ctor 而已，什么大惊小怪的。
自己写不出来，非得让语言设计者替自己钦定还觉得光荣的斯德哥尔摩综合症患者，就 C 用户里特别集中，就别怪人不鄙视了。
当然 C++ 这种缝合怪也不是啥好鸟，顺手就给 ptr 加塞个&（ C++/CLI 再糊了个^)，也是糟粕。但是讲道理，&创建的类型还就比你*这种横竖都跳不出 object type 的破烂货特殊，本就更有资格当套套了。

> 比如 if constexpr ，可以让我的代码编译期做判断提升性能，但是我忍住没用了，改用模板和宏去模拟，为啥？

模个屁股，一个 tag dispatch 就能看清楚的东西还画蛇添足套省不了什么代码量的宏，嫌弃可读性太高了？
还是你就在口嗨连怎么实现都没想象过？

> QString 有多强，你可以学习下：

QString 还就是 GotW#几（懒得找了）里提过的 basic_string 垃圾之处的威力加强版——一坨跟实体类型无关的非必要接口乱七八糟地堆在类定义内。
放外面会死？
什么 Latin1-centric 的笑话我就不多婊了。

> https://www.zhihu.com/question/54664311/answer/140476787
> 与其说它是个字符串，还不如说它是个处理二进制数据的 buffer ，基本等同于 std::vector<char>。

什么煋……
string 的本义就是叫做 alphaset 的集合的元素能生成的序列，什么“字符”（包括 char_traits 之流）是瞎扯的，搞不好历史上就是一坨妄人对 alphabat 望文生义出来的缝合怪。
发现不了这个的真是数学基础不牢靠。
当然，也不全是用户活该。C++ vector 就是个垃圾命名，真正勉强能算上 vector 在 C++里叫 valarray 。但再垃圾，也是垃圾不过 C 把 B 里好好的 vector 硬叫成 array 开启打乱萝卜坑的妖风的。
（ SSO 什么破烂的既然该答主应该也不够格纠结，略过。）
——然后，吹 QString 当“字符”串的习气比 C++的设计更加数学丈育。

> 大道至简，这个 PyStand.cpp 很简单
经典 CS 笑话：Py 能映射到“大道”和“简单”上。
（只是顺便，没特别黑你的意思，说实话我懒得看内容。）

> 又来，我跟你说了我希望尽量限制标准在 14 及以下，你完全 get 不到我的角度。

string_view 这种 C++11 子集就能实现个大概的东西都糊不会，非得像什么 QString 之流的垃圾设计风格看齐，这根本就是脑子里的浆糊问题。
真是实力不够拎不清楚怎么实现，抄个 abseil 会死啊……

> 我觉得写代码让更广泛的编译器支持我的代码的意义，比只知道无脑飙 C++ 版本更有意义。

什么无脑飙版本，你当是 Google 炒肉末吗？
C++那么多改得罄竹难书的垃圾不会举例，夏虫不可语冰还要 inline expansion 一下凑字数是不？
我教育你俩例子：lambda default capture 和 u8 literal 这俩货被 C 艹 20 改的是没法让前后代码安生的（要么条件包含，总之基本不能只写一遍兼容不用标准）。
这才是比什么版本号更确切的工业级傻逼。
但是 Qt 这种第一个 minor 版本 deprecate 第二个 minor 版本就整个把 API 干掉的明显更加十足地工业级傻逼。自行领会。
“没做过啥真实交付项目的人，说一百遍他都领会不到。”这就是正确的废话。

> 觉得恶心的话你去跟标委会那帮子鸟人提案，让他们把指针从 C 艹 下个版本里删掉啊，我乐见其成，看看他们听你的不。

脑子有坑吗，干嘛要浪费时间在糟老头子身上？（“实际深入点的经验全无”——你这是没对付糟老头子的经验的自供吧？）
虽然没法 #pragma GCC poison 是弱鸡（看，又是个 * 比 unique_ptr 严格烧饼的地方），但是退一万步也不碍着我能人肉 review 不给你过啊？

> 计算机领域很多，别总在你熟悉的那个领域里打转

又是废话。
但看得出你倒垃圾又不需要多有熟练度，阻碍你乱倒垃圾也不需要几点武力值啊？

> 所以说你从来只看得到一，看不到二三四。BasicBitmap 里，老衲前面已经给 inline `#define` 成具有 always_inline 属性的宏了，你是眼睛瞎了看不见，还是不知道什么叫做 always inline / force inline 啊？

我懒得看，不过你这样直接 UB ，半轮 review 内会被打死。

> 程序员别成天只知道代码，别满脑袋都是技术，走向社会要吃亏的，有空多了解下技术以为的人文知识，荀子曾说：“故不问而告谓之傲，问一而告二谓之囋。傲、非也，囋、非也；君子如向矣。”，看不懂的话我给你翻译一下，荀子他老人家说：“别人没有问就去告诉的，叫做急躁，别人问一个问题而告诉别人两个问题的，就叫做唠叨”。

你要多知道点人文知识就可能知道几十年前吹这个搞不好是得被查成分的。
而现代人不兴这个，其实主要就是懒罢了，犯不着对一个连“学阀”都不沾边的市井路人闹情绪。
但这不表示拦住你倒垃圾就很费劲。
ky 啊 ky 。

> 动不动就 “你看看 A 去”，“你知道 B 吗？”，生怕别人不知道他懂一般，在荀子口中都是君子为人需要避免的东西，计算机领域博大精深，谁都有不知道的东西，动不动就想教别人一下，在你小圈子里没问题，出了圈还这么着，不能教而强教，担心闹笑话。
什么荀子，过气了。
时兴点说，不懂还好为人师的，那是民科的一个子类型。

> 但是 strict aliasing 这种傻鸟设计的东西不一样，这属于当年标委会那帮子鸟人设计出来的缺陷东西

傻鸟的是把 C 抽象机当做 PDP 破烂用的过气货色。

https://queue.acm.org/detail.cfm?id=3212479

明明几乎就没可能摸过 PDP 却在这种旮旯地方还杠上了，不是靠 spec 而是靠脑补出来的 model 来定义语言应该长什么样，这大约是谭浩强隔代传人 8……

你 C 甚至都不算个 PRAM(parallel random-access machine)（当然真机器也不是） ，能日字节寻址的 memory 什么时候变成优势了？

> 全部遵守的话，让那帮象牙塔里的人来用当年的标准（不用 bit_cast 这些 20 里打补丁做裱糊的东西），他们都很难写出正确的 memcpy ，这不搞笑么？

这更扯蛋。什么时候 C 保证 memcpy 的实现可移植了？在任何一种精神上——除了你自己脑补——都没有。（又不是 LISP 这么吹几个 primitive 剩下都能 derive……）

只是要可“移植”，__builtin 又不会死……

> 是不是眼红 java/clang 的优化牛逼，自己又没本事进一步优化

就是为了让没事脑补有个可以按字节寻址的不确定具体配置的地址空间这种傻逼抽象彻底滚粗可移植代码。

优化反倒是次要的事。真恶心你就该 bb 什么 std::launder ，但明显本事不大够。

> 为实践服务，不用反过来

实践不是那坨互相瞎吵但最终还是达成共识的糟老头子定义，难道还轮得到你定义了？
按你说的，你有什么把 strict aliasing 踢出标准的动议过？

> "状态机" 拷贝下来和我说，任何 API 都有不完美的地方，状态机是 OpenGL 不完美的地方

所以你这个没 CS 系统训练见识过 model 的人就是不懂什么时候该收声。

状态机为什么欠扁？不仅仅限于是 API 难用那么种表面的性质，根本上是反人类——要求人理解足够多（经常还预测不了上限）的状态之间的全局交互属性才可能精确捕获系统的演化性质。这可能于简化物理实现，但对向人阐明原理和意义 model 来说，就是半成品。（就半成品拉仇恨方面，指针满天飞的破烂和没 resolve 干净 ownership 的没事瞎依赖 GC 的废物程序是类似的其它例子。）

更深层地说，状态机之类的东西和还原论根本不搭——难以可行地证明范式或者最简形式。因此如果要当做逆向设计的终点甚至当做像模像样的理论，多多沾点炼丹伪科学的味儿。

即便是描述计算模型这样最通用的领域也一样——用状态配置描述的图灵机之流有一大坨备胎；相比之下，无类型 lambda 演算就基本上算是独一无二的，多一点太多，少一点太少——再干掉一些东西就几乎必定会失去主要的性质，而要加个保守扩展就会引入 non-trivial 的其它东西，而值得作为还原设计的终点，扩展设计的起点。

题外话：

1) 王垠批评 Lamport 还有那谁的东西有“状态机”是多余的（算是难得没在扯蛋），说白了也是类似的道理。
2) 都吹什么人理解迭代、神理解递归，我看其实是人理解递归，神棍和狗屎把递归替换成莫须有的状态还差不多。

到此还不算直接在批评 OpenGL 。但是当有比较的时候，哪个设计更加裸泳就一目了然了。

> 不要生活在真空世界里了，C++ 比你厉害十倍的人我也经常和他们交流，真的懂 C++ 的根本不会像你这么阳春白雪。

和你交流？谁啊？
或者你跟我重复一遍？不怕溢出遭天谴的话？

> 著名项目，Qt / wxwidgets ，看看他们是不是指针到处飞？
著名和质量垃圾有矛盾吗？
std::basic_string 那么弱鸡的玩意儿都找的到垫背的设计（除了从 C 引进的），也是活久见。
虽然倒是很容易甩锅“因为它们更老”。

> 图形领域的各种 3D/2D 引擎 Ogre3D / Unreal / urho3d 哪个不是飞指针
虽然没有冒犯的意思，我还是承认很庆幸我不对这方面感兴趣而不用吔屎了……

> 他们懂啊，局部用，用也是用自己实现的，看不上你 std::xxx_ptr 。
之类玩意儿么，周知的除了转进投靠 std 的 EASTL 之流，属实懂个鸡脖了。

> 系统开发领域唯一的 C++ 内核 Fuchsia
不懂装懂孤陋寡闻也别那么明显好不。
先吃个 L4 全家桶屑屑。

> 你但凡读一两个上面这类各个领域的著名项目，
但凡你批判不了所谓的著名项目有哪里妥协以及看不出下限在哪，就容易让人觉得你钦定什么著名的资格很可疑。

> Qt 解释过自己为啥用裸指针，以及他的所有权管理
很多人解释过自己为啥不用指针，或者不用 Qt ，或者鄙视 Qt 的扯蛋所有权（因为不方便看到 new 就 review 对照权限一棍子打死而成本捉急）。
当然，不是说 std 就一定比 Qt 好哪去了。前些年还有提案图形库还顺带搞进去按键输入的笑话。但是就所有权这块，除了 BS 的 observer_ptr 口水，还是别鸡蛋碰石头了 8 。
不管 Qt 怎么解释那个什么 tree ，需要人多记住特设规则的反人类的属性不会变。（这是导致不能方便打死 new 的背后的原因，但不仅 reviewer ，别的用户也被坑。）

>> Qt has its own ownership system that must be respected

Respect 包含直接不用。
就像 Rust 对付解决不了的破烂也有 unsafe 直球干掉保证这招。

> 工作上 C 艹 写的比你牛逼的人多的是

说真的，C 艹 写的不比你牛逼的，还真敢用 C 艹 嘴硬死不认怂歪理一套套，以至于我能毫不费劲一路婊到底都不太需要多过几次大脑的，还真没见过几个。