当一个问题存在两难时，市面上就不太可能出现稳定的，大众化的解决方案。

这很多是一个哲学问题
两害权衡，
存在很强的个性差异.

这种问题需要自己解决，
这个就是为什么要使用Emacs或者Vim的原因。

今天分享的一个想法，就是调用跳转树的处理方案。
由于这里的操作很大的个性化及手工化，没有很合适分享的代码，只是提出方案，抛砖引玉。

摒弃IDE的一个后果就是无法方便的查看函数的调用栈.

在阅读源代码时，我们经常会经历这个刨根问底的过程：

• A函数调用了B函数
• 查看B函数的定义
• B函数又调用了C函数
• 查看C函数的定义
• …
• 如此反复，直到见底为止

而且这个过程要反复多次，因为需要反复琢磨，特别是一些大型项目，或者写得特别烂的代码，
没有几次来自跳转，不可能看明白。

那这个过程，是IDE可以解决的吗？

有个实战经验的人应该知道，IDE只是帮忙你跳到下一步，并不会记录这个过程，
这个过程才是重点，它是你思维流。你想到哪里，又从哪里想起另一个地方。
这个过程只有你自己才能记录，没有什么工具可能完成这样的需要。

因为记录的工作只是第一次要做，后面只是修补，是一种低频工作，所以可以手工完成!

我的方案是手工制作，利用脚本，做到半自动。

前期方案

我在Vim中与Emacs中都分别实现过这样的树，感觉非常精美，而且对付小项目非常实用。

目前方案

当我遇到QMK时，上面个方案几乎Hold不住了，
因为QMK源码非常庞大，从程序入口到最后的USB驱动，调用深度可以上20层！
这个时候，你要想办法折叠子树，不然这个树太长没有办法看。
另外如果要移动子树，还有大量工作要做。

当我发现Org这个包管理的标题深度不受限制时，我放弃了上面的方案，直接把标题当树节点，Org文档当成树！

Org自带的功能可以维护层次结构的树，包括子树折叠与展开，子树的整体移动，这些功能完美地克服上面的问题。

你要做的就是再写一些代码，以方便增加Org标题及增加跳转到指定文件某行的功能。

这个树虽然没有上面的精美，但非常实用，没有这个方案之前，我根本读不懂QMK源码。
利用Org的优级子树管理功能，现在我才能比较清楚QMK的来龙去脉，并解决一些个性化需要，像前文提到Ctrl-Alt-Shift-F13组合键。
QMK是一个Game changer，非常重要，直接的后果是Emacs可以开始正常使用，Emacs可就不是一个Game changer了，而是一卡车！

很显然没有这样的工具，单凭IDE或者其它语法分析工具，是无法完成复杂项目的阅读的。