我之前已经问过这个问题（Locating unmatched delimiters in Clojurescript），我仍然没有足够的答案。
我想对读取器检测到参数不匹配等错误的行发出警告。 Clojure通常只抛出一个非常一般的错误，只命名文件但没有行等等。
我想要一个
我现在已经找到了我的问题，并希望对我遇到的问题更加准确。我正在编译分布在几个文件上的代码的Clojurescript。当我发现代码不再编译时，我知道我对其中的三个进行了更改。该错误消息是关于)行中文件a.cljs中1不匹配的信息。但我很确定，我没有大幅改变a.cljs。
因此，当我发生这种错误时，我采取了常规方式（不常见）。
这次我没有轻易发现变化。最后，我发现该问题在文件的一部分中缺少]，其中括号括起来，即某些其他文件)]))])中间的c.cljs。出于某种原因，vim clojure没有更多或错误地缩进以下函数，因此基于“检测”的缩进不起作用。
我认为，为什么clojure读者不能很好地吐出这些不匹配的位置，这可能是一个很好的理由。请不要理解我的问题是为了劝说。在寻找一个地方很长一段时间后，我写了一个小的（~50行）基于堆栈的括号匹配程序（用C ++我不得不承认）处理{([ ; - 评论和简单"字符串 - 没有任何接近正确的解析器，但它指向了正确的行和字符。
就Clojure错误消息的质量而言：一些很差，但我大多没有抱怨，因为Clojure的语法非常简单，以至于我只是让语法正确（语义是一个不同的主题） ）。然而，对于一个lisp在不匹配的parens上提供如此糟糕的错误消息有点不走运，特别是对于之前没有使用过Lisp的人。我知道paredit，我已经使用过它（至少是vim-paredit），它是一个很好的工具来处理s表达式。然而，它确实使一些事情变得更加复杂，并且我在混合paredit和vim-fugitive方面遇到了不好的经历。
根据建议对clojure核心进行黑客攻击和贡献：实际上可能是一个选项，虽然在浏览源代码时需要花费很多精力才能深入研究。虽然目前我觉得自己更喜欢写一个小单 - 与leiningen一起使用的目的工具，它可能更简单。
我觉得我的帖子在某种程度上激怒了一些人。这并不意味着要讨论clojure项目，我真的很喜欢clojure开发人员为我提供编程语言。
答案 0 :(得分：2)
报告错误消息的一个原因并不是更好，这是一个理由而不是借口，大多数使用Clojure的人使用 paredit-mode 或等同于添加括号自动使得它们很难不匹配。虽然我知道它并不适合所有人和每个编辑，但是paredit的存在可能有助于解释为什么没有更多的协同努力来解决这个问题。
Clojure是一种非常年轻的语言，无论信不信，错误消息比过去好得多。越来越多的Clojurians正在认真考虑编译器中的错误报告，并且这些错误消息有望得到改善。抱歉沮丧。该语言有很多部分可供使用，至少在某种程度上我理解这一点。一如既往地欢迎补丁！