我之前问过这个问题（Locating unmatched delimiters in Clojurescript），但我仍然没有足够的答案。
我想在阅读器检测到参数不匹配等错误的行得到一些警告。Clojure 通常只会抛出一个非常普遍的错误，仅命名文件但没有行等。
我想要一个
- 提供此信息的 clojure 特定工具（类似于 lint 工具）
- 关于阅读这些堆栈跟踪的建议
我现在发现了我的问题，并希望更准确地了解我遇到的问题。我正在编译分布在多个文件上的代码的 Clojurescript。当我发现代码不再编译时，我知道我已经对其中的三个进行了更改。错误消息是关于在线)文件不匹配的。但是我很确定，我并没有发生实质性的变化。a.cljs1a.cljs
因此，当发生此类错误时，我采取了通常的执行方式（这种错误并不经常发生）。
- 用 vim 缩进整个文件，看看缩进是否“疯狂”。
- 使用 git diff 查找我的工作副本中的更改和最近的历史记录（我进行粒度提交）以查找我最近更改的位置。
这一次我没有那么容易地发现变化。最后我发现问题出]在文件的一部分中，其中右括号堆积起来，即像)]))])在其他文件中间的东西c.cljs。由于某种原因，vim clojure 没有更多或错误地缩进以下函数，因此基于缩进的“检测”不起作用。
我意识到，clojure 阅读器不太擅长吐出这些括号不匹配的位置可能是有充分理由的。请不要将我的问题理解为居高临下。在找了很长一段时间后，我编写了一个小的（约 50 行）基于堆栈的括号匹配程序（我不得不承认在 C++ 中），它处理-{([ ;注释和简单的"字符串 - 没有什么接近正确的解析器，但它给我指出了正确的行和字符。
就 Clojure 错误消息的质量而言：有些很差，但我大多没有抱怨，因为 Clojure 的语法非常简单，我大多只是把语法弄对了（语义是一个不同的主题）。然而，对于一个 lisp 来说，在不匹配的括号上给出如此糟糕的错误消息有点不走运，尤其是对于以前没有使用过 Lisp 的人来说。我知道 paredit，我用过它（至少是 vim-paredit），它是处理 s 表达式的好工具。但是，它确实使一些事情变得更加复杂，并且我在混合 paredit 和 vim-fugitive 时遇到了不好的经历。
按照建议对 clojure 核心进行黑客攻击并做出贡献：实际上可能是一种选择，尽管在浏览该源代码时确实需要付出很多努力才能深入研究。尽管目前我更喜欢编写一个小型的单一用途工具来与 leiningen 一起使用，这样可能更简单。
我觉得我的帖子在某种程度上激怒了一些人。并不是要贬低 clojure 项目，我真的很感谢 clojure 开发人员为我提供了编程语言。