@hinataharuki 回答老哥这个问题。让我突然发现，思维方式才是本质。有启发。感谢。

@hinataharuki 后面又谈到了教育，最后又涉及自我的探索。然后又下沉到具体。看上去无章法，但是确实有点出发，一层层进入又最后出去的过程。堆积了链表式的思维方式。

@ipwx 其实，上面说的也不全对。易经里面有很全面解读。万事万物按照规律来。也许是我个人问题比较重。或者遇到问题，看到的不是问题本身，反而更容易放大到更大问题。所以，就会进行完全不可所以的漫天探索。
https://www.sohu.com/a/451029349_100162106

@ipwx http://www.xueshucn.com/p/8514.html

@wufumina 赞。拉升了层次。我也觉得有一点是不完美的，就是，‘君子’。君子未必是君子，别人未必，自己也未必。生而为人，和而不同。意义更在于能共同成长，相同体验。非常赞的是强调了一点。就是，‘和’。

深入了情商的核心。甚至驳倒了情商的形式。让受到情商困扰的人能够看开。正确理解关系的本质。不过，理解方面，是相互的。更加重要的是，识别对方理解层次，和自己的理解层次是否一致。做出和谐的判断和行为。

@czfy 没有刻意的任何修饰和任何逻辑，即没有行文结构可言。因为这本来就是漫天飞舞的思考。因为初衷根本不知道要说啥，只是大脑各种信息胡乱的关联。企图，获得在不断的凌乱中，寻找尘埃落定的规律。

错别字问题，或者其他过于形式的问题。本文没有考虑。只是尽情写。散乱至极。拼音输入法存在的权重问题，以及我没有纠错。这东西本来都不重要。所谓的废话。意思懂即可。重要的是有共同思绪或者喜欢这种思绪的朋友。一起去能交流甚至去享受。这个本质的东西。自我的想法有限，灵感也许就从各位的口中出现。

@kop1989smurf 我发现，我越来越没有三观了。我喜欢是因为我认同。但是当我理解不认同的原因。就会让我感觉，我喜欢的一文不值。有种陷入，我谁也不想选的的迷茫中。我觉得，我不存在了。或者，存在形式变成了不存在的存在形式。思想方面不执着也不异想。理念和概念等思想问题变成了以无解作为答案解开。不重要了。反观现实的吃饭睡觉，貌似重要了不少。

中午吃红烧肉吧。挺香。

内向未必是真的内向。据我了解。有一种人不爱说话，是因为不想说废话。还有一种人是因为觉得说话没有意义，而不爱说话。主要看是哪一种。也可能是其他。第一种人，适合搞研究，第二种人适合过得具体一点。

@LemonK 前辈。

@h1104350235 @eghao 哈哈，是呀。老哥们描述的是，一个角度的正反面。舒服感体现的情商。不舒服感体现的低情商。主要还是结果评价。以及深入讨论了，这一方面的，判断的严谨性。

整理了一个简单的架子，来自已发表见解的兄弟们的智慧：
@cmdOptionKana 情商的意义。到底需不需要的问题，情商在做一件什么样的事情。
@maocat 情商的结果评价。哪一种外在现象，说明以及具备了情商。
@wolfie 情商，在不同的人群中，是怎么表现的。以及哪一类人群，具备，或者不具备。针对人群的指引。
@mineralsalt 理解什么是低情商表现。
@pffrank 正常的情商，具体的操作方式。
@libook @leonard 情商要求的本质能力
@blackshow @bibizhang 表达了对此问题的关心，和支持。
继续补充，是不是还有兄弟没发表看法？期待继续补充丰富环节和细节。

@DuDuDu0o0 好的。我用的是按照自己的理解去选合适的配色。之前确实没有听说过自称这种目标的配色方案。 我目前用的是 rainglow 的 Darkside 。可以试试。满足我对语法着色的需求，颜色搭配挺刺激。

@DuDuDu0o0 配色不仅仅是用来观赏的，更重要的是，能够通过色彩帮助更快阅读代码。比如，静态方法，静态变量。局部变量，方法入参，等等。色彩越多，区分的就越多。而且，并不是所有配色都具备这种能力，在这方面有能力差异。

有没有挑选 color scheme 的标准除了护眼，是通过语法标注的数量的？

涨知识了

面试的时候，为何不把 vim 作为一个指标？

@kkocdko 不过这样就和 autosave 绑定了。虽然想要绑定 save ，但是不期望绑定 auto 。

基于 vscode 自动延迟保存的方式，固定了频率，但是也出现一定会触发的频率。

想要一种既可以保持最低频率，但是不想要固定周期的效果。（因为固定周期会触发很多次 git 命令。）
目前的逻辑设计为，通过 ctrl+s 引发保存操作，且不会因为人为的高频 ctrl+s 操作，导致后续命令高频触发。同时延迟控制，需要两种模式，一种低速模式，在日常的编写过程中，一种是快速模式，当我想要关闭编辑器的时候，以及当我想要主动快速触发，push ，联动 github 上面的 workflow 。

目前的这个代码实现，已经满足这种逻辑。只是，在延迟上，遇到不精准的问题。能用但难受。

无意中发现 inputbox 的调用产生了缩小延迟的效果。使得我有了点优化延迟的期待。

目前，我的思路就是，搞清楚 inputbox 的加速核心关键。找找有没有哪些具备加速核心，并且是在后台执行的，并且没有啥影响的。方法调用存在。

这个加速关键个人猜测就是使得 nodejs 将 io 操作甩给了线程池了。无力研究。求教一下。

感谢老哥的思路。

@enki0423 没有为什么，因为宝宝想要。一共绑定了两个命令用于外部触发。但是也有 onsave 事件触发的逻辑。
onDidSaveTextDocument 触发，依赖于自己保存文件的操作。这个操作频率很高。想要降频。

复现方式：修改函数，返回 true.开启状态。https://github1s.com/fanlushuai/vscode-note-sync/blob/HEAD/src/note-sync.ts#L31-L32
f5 直接运行调试。
在调试窗口。打开输出日志，sync-note 那个。查看输出。
调用命令，syncQuickly 和 requireAction （呼出 inputbox 之后，可以直接回车）。查看日志输出表现。反应出来速度差异。