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