Hi Meikel,

Regarding namespaces, I would appreciate help understanding what looks
like a heisenbug.

I have a file at t2/data/core.clj, with namespace t2.data.core
The namespace (ns t2.data.core) does not :import or :use anything.
I open such file by :edit t2/data/core.clj
When switching to another buffer and then back, sometimes it complains
with a long error, the now famous line 23 nail error. But sometimes it
does not (?). Restarting vim solves this problem, until it catches on
again. It would help a lot if the error was more specific: which
expression failed? What was the nailgun trying to do? The current error
basically says nothing other than "an error ocurred in the nailgun".
The shell where the nailgun server was opened doesn't print anything. It
would be a good place to print this nailgun server indigestions.

Also to note here that these multiline nailgun errors are a pain to have
in the vim minibuffer, for one has to press return several times until
the entire message of the error is printed in full. A Scratch buffer or
the shell where the nailgun runs would be a better place, leaving
perhaps a single line such as "Error: check ng shell" in the minibuffer.


Regarding the \sr Repl:

On occasions, it throws an error, altough the Scratch buffer opens
anyway with an inactive Repl in it (the cursor is at the top instead of
after the prompt, and no expressions may be entered with return.) If I
close it with esc :bd, and retype \sr, then the Repl opens fine.  It's
puzzling. And happens at random times.

Also: the \sr Repl becomes (again, sometimes) irresponsive (i.e. doesn't
evaluate anything) when I accidentally press control+w control+w while
in insert mode, which deletes one or two lines, depending upon when I
realize so. What is the proper way to reenable it, short of :bd and \sr
again?


It's true that most errors are on the user side. I've experienced this
both as user and as developer receiving bizarre complains from users of
my software. I my experience, detailed how-tos with detailed, precise
examples of operation go a very long way, much more than any description
in a manual.

Thanks for VimClojure. I'm loving it despite all the unexpected
reactions.

Albert
-- 
Albert Cardona
http://albert.rierol.net


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to