Syntax errors in Clojure source result in InitBuffer exception that suppress plugin mappings

Issue #7 resolved
Joe Holloway
created an issue

I have seen in a few places (most recently on StackOverflow [1]) that people are having issues with their VimClojure key mappings. Most of the troubleshooting revolves around trying to figure out how to correctly use the "local leader".

However, I think I have found one possible source of confusion.

If you are loading a Clojure source file into a buffer and this source file is not syntactically correct, the "NamespaceOfFile" nail will understandably fail to execute. The resulting exception is eaten inside the vimclojure#InitBuffer function [2] and the "b:vimclojure_namespace" variable is left undefined.

The filetype plugin checks for existence of the "b:vimclojure_namespace" variable prior to defining the full set of VimClojure mappings [3]. Thus, the syntax error has the side effect of preventing the mappings from getting defined.

When the user tries to start a REPL, for example, the <LocalLeader>sr combo will have no effect, which makes it look like VimClojure is not installed properly when really the problem is in the source file.

In my opinion, loading a source file that contains syntax errors should be a valid use case for the plugin. For example, maybe I need to fix the syntax errors and then send the code off to the REPL for testing.

I would be happy to work on a patch for this, but I'm afraid that simply setting a default namespace (e.g. "user") when the "NamespaceOfFile" nail fails is not the best course of action. Thoughts? Is there danger in assuming namespace of "user" when the namespace of the source file can't be determined because of evaluation failure?

PS Thanks for the hard work on the plugin, it is very slick.




Comments (3)

  1. Meikel Brandmeyer repo owner

    I'll try to investigate, whether we can use the return value of the ng client to judge what's happening on the other side. But I somehow doubt, that we have consistent exit codes in v:shell_error across platforms.

  2. Meikel Brandmeyer repo owner

    The reason is the dynamic highlighting which examines really all existing Vars in the namespace dependencies and colors everything 100% correct whether it's a macro or function. However, if there is a failure the exception bubbles out of the syntax highlighting code and the initialisation is stopped.

    For now we simply catch the exception and provide only basic highlighting. But beware, that sending code most likely won't work 100% correct! While the previous explosion made that clear, this much more subtle now.

  3. Log in to comment