Substantial changes for VimClojure - Please test!
Meikel Brandmeyer
I made some substantial changes to VimClojure. My hope is that things
get more robust now, and if they break the diagnostics should be more
usable.
First the profane changes: the names of the configuration variables have
been unified to be more consistent. You will be pointed by messages to
the new names. Also syntax highlighting is now enabled by default. The
only sane default…
The communication between Vim and the Clojure side is now covered by
some kind of protocol. I hope that especially problems are communicated
now more clearly, because things are displayed in a buffer and not as a
hard-to-read-and-copy message. These changes should be mostly
transparent and you should not notice any difference in normal usage.
Please test the snapshot and let me know of any problems, so that I can
iron out things for the next release. For me things work pretty well,
but experience shows, that this does mean nothing in the wild.
The snapshot can be found here. Put the jar on the classpath and unzip
the zip into your .vim directory. Note: Tim Pope's pathogen[1] might help
you experimenting here.
http://kotka.de/snapshots/vimclojure-2.2.0-SNAPSHOT.jar
http://kotka.de/snapshots/vimclojure-2.2.0-SNAPSHOT.zip
Sincerely
Meikel
Lee Hinman
I've been playing with the new release, working great so far. I've run
into one problem with the completion. When I try to cycle through the
completion options and reach a Java ctor (in this example), hitting
ctrl-n one more time closes the completion window with a "Pattern not
found" error, which can be very annoying if the completion I want it
right above the Java ctor. I not 100% sure if this is a VimClojure
thing or something wrong with my completion setup.
Here are links to 2 screenshots, the first [1] where the cursor is on
the completion menu before hitting ctrl+n and the second [2] is the
error that is generated hitting ctrl+n one more time.
Thanks,
Lee
[1] http://imgur.com/3BBa8.png
[2] http://imgur.com/H4mlE.png
Meikel Brandmeyer
On Sun, Apr 04, 2010 at 04:06:57PM -0700, Lee Hinman wrote:
> Here are links to 2 screenshots, the first [1] where the cursor is on
> the completion menu before hitting ctrl+n and the second [2] is the
> error that is generated hitting ctrl+n one more time.
I'm a little bit confused about the screenshots. The first looks like
the built-in completion (<C-n>) (the completion menu does look like the
one of the built-in completion as well as the fact that Java ctors are
offered for completion) while the second talks about omni completion
(<C-x><C-o>). If it is the built-in completion, I can't do anything.
This is really a Vim feature, where I just provide static information
for clojure.core + plus whatever is in open files.
Could you clarify?
Sincerely
Meikel
Mike Mazur
On Mon, Apr 5, 2010 at 05:52, Meikel Brandmeyer <m...@kotka.de> wrote:
> I made some substantial changes to VimClojure. My hope is that things
> get more robust now, and if they break the diagnostics should be more
> usable.
>
> [...]
>
> Please test the snapshot and let me know of any problems, so that I can
> iron out things for the next release.
I've given it a spin tonight. It feels stable to me, too, and faster
even :) No signs of my earlier clojure.vim processing errors[1].
One non-intuitive thing was the .clojure file which the nailgun-server
launcher uses to add items to the classpath. I expected I could just
list entries, one on each line, and the script would Do The Right
Thing. However I discovered that I needed to place a colon at the end
of each line for the nailgun server to launch properly. It's a minor
detail, probably not worth solving properly in the script itself.
Good work Meikel! Thank you, much appreciated.
Mike
[1] http://groups.google.com/group/vimclojure/browse_thread/thread/c77e7299033b36cc
Miki
> First the profane changes: the names of the configuration variables have
> been unified to be more consistent. You will be pointed by messages to
> the new names. Also syntax highlighting is now enabled by default. The
> only sane default…
I had an old "let g:clj_highlight_builtins = 1" and for some reason
all the closing parents were highlighted as errors.
> Please test the snapshot and let me know of any problems, so that I can
> iron out things for the next release. For me things work pretty well,
> but experience shows, that this does mean nothing in the wild.
Just a tiny think, but \si and \sr are mapped also by the svn plugin.
All the best,
--
Miki
Meikel Brandmeyer
On Mon, Apr 05, 2010 at 07:23:34AM -0700, Miki wrote:
> I had an old "let g:clj_highlight_builtins = 1" and for some reason
> all the closing parents were highlighted as errors.
Hmm… This is rather ominous. I highlight things using echoerr. This
might be a problem inside a try. Although „that should never happen.“
(On Windows there might be a problem, because the Windows vim loads
syntax files before filetype plugins.)
I will change things to a warning message instead of using echoerr.
> Just a tiny think, but \si and \sr are mapped also by the svn plugin.
Well. That cannot be resolved. I can't avoid all good mnemoics because
some other plugin might use them also.
However, VimClojure is following the guideline for plugin developers as
closely as possible. So in that sense it is well behaved. In your case
this means, that you can define your own key mappings.
augroup MyClojureMappings
aucmd BufNewFile,BufRead *.clj nmap <buffer> <LocalLeader>Sr <Plug>ClojureStartRepl
augroup END
Not tested, but should do the trick. VimClojure recognises, that there
is already a mapping to the Plug and doesn't define its own. The plug
names are given in the online help file in the doc subdirectory.
Using pathogen helps again here. Then you can create your own
~/.vim/filetype/clojure.vim containing all the mappings and the „real“
plugin is later on loaded from the bundle directory.
Sincerely
Meikel
Meikel Brandmeyer
On Mon, Apr 05, 2010 at 10:08:17PM +0800, Mike Mazur wrote:
> I've given it a spin tonight. It feels stable to me, too,
That's a good …
> and faster even :)
… and that's subjective, I'm afraid. :) Things are dominated by calling
out to the nailgun client. On my MacBook this is hardly noticeable. On
my crappy Laptop at work it's slightly annoying. If at all things should
be a bit slower since more work has to be done. But as I said: it should
be not noticeable.
> No signs of my earlier clojure.vim processing errors[1].
Good. Although I don't like not understood, vanishing errors.
> One non-intuitive thing was the .clojure file which the nailgun-server
> launcher uses to add items to the classpath. I expected I could just
> list entries, one on each line, and the script would Do The Right
> Thing. However I discovered that I needed to place a colon at the end
> of each line for the nailgun server to launch properly. It's a minor
> detail, probably not worth solving properly in the script itself.
Woops. This is a bug. Will fix it.
Sincerely
Meikel
Lee Hinman
Lee Hinman
similar to Clojure forms. When I call the function from a regular REPL
there's no problem, but doing an ,el on the same line with VimClojure
throws all kind of strange errors, it almost looks like it's trying to
eval the output.
Here are the lines from a regular REPL:
‹ ~/src/clj/clojure-opennlp › ∴ java -client -Xmx2048m -cp
'src/:classes/:/Users/hinmanm/.m2/repository/leiningen/leiningen/1.1.0/leiningen-1.1.0-standalone.jar:src/:lib//clojure-1.1.0.jar:lib//clojure-contrib-1.0-20091212.214557-33.jar:lib//jsch-0.1.42.jar:lib//lein-clojars-0.5.0-20091119.123056-6.jar:lib//maxent-2.5.2.jar:lib//opennlp-tools-1.4.3.jar:lib//trove-1.0.2.jar::'
jline.ConsoleRunner clojure.main
Clojure 1.1.0
user=> (use 'opennlp.nlp)
nil
user=> (def treebank-parser (make-treebank-parser "parser-models/build.bin.gz"
"parser-models/check.bin.gz"
"parser-models/tag.bin.gz"
"parser-models/chunk.bin.gz"
"parser-models/head_rules"))
#'user/treebank-parser
user=> (println (.show (first (treebank-parser ["This is a line ."]))))
line: This is a line .
tokens: This for: This is a line .
tokens: is for: This is a line .
tokens: a for: This is a line .
tokens: line for: This is a line .
tokens: . for: This is a line .
(TOP (S (NP (DT This)(NN i))(VP (VP (VBZ s)(ADJP (JJ a l)))(CC i))ne .))
nil
And here's the error from VimClojure when doing the same thing (I
apologize for the wall of text) I replaced all the \n with actual
breaks so it was a little easier to read:
Error detected while processing function
vimclojure#EvalLine..vimclojure#ExecuteNailWithInput:
line 26:
E121: Undefined variable: DT
E116: Invalid arguments for function NP (DT This)(NN i))(VP (VP (VBZ
s)(ADJP (JJ a l)))(CC i))ne .))^@{"value" : 0, "stdout" : "line:
This is a line .
tokens: This for: This is a line .
tokens: is for: This is a line .
tokens:
a for: This is a line .
tokens: line for: This is a line .
tokens: . for: This is a line .
nil
nil
", "stderr" : ""}
E116: Invalid arguments for function S (NP (DT This)(NN i))(VP (VP
(VBZ s)(ADJP (JJ a l)))(CC i))ne .))^@{"value" : 0, "stdout" : "line:
This is a line .
tokens: This for: This is a line .
tokens: is for: This is a line .
token
s: a for: This is a line .
tokens: line for: This is a line .
tokens: . for: This is a line .
nil
nil
", "stderr" : ""}
E116: Invalid arguments for function TOP (S (NP (DT This)(NN i))(VP
(VP (VBZ s)(ADJP (JJ a l)))(CC i))ne .))^@{"value" : 0, "stdout" :
"line: This is a line .
tokens: This for: This is a line .
tokens: is for: This is a line .
tokens: a for: This is a line .
tokens: line for: This is a line .
tokens: . for: This is a line .
nil
nil
", "stderr" : ""}
E15: Invalid expression: (TOP (S (NP (DT This)(NN i))(VP (VP (VBZ
s)(ADJP (JJ a l)))(CC i))ne .))^@{"value" : 0, "stdout" : "line:
This is a line .
tokens: This for: This is a line .
tokens: is for: This is a line .
tokens: a
for: This is a line .
tokens: line for: This is a line .
tokens: . for: This is a line .
nil
nil
", "stderr" : ""}
line 27:
E121: Undefined variable: result
E15: Invalid expression: result
Error detected while processing function vimclojure#EvalLine..492:
line 2:
E121: Undefined variable: value
E15: Invalid expression: a:output.value == 0
I'm attaching a screenshot of what the error looks like from inside
Vim as well as the text of the correct REPL output and VimClojure
output. I'm really not too sure what's going on other than it looks
like VC is trying to evaluate the output as Clojure code.
- Lee
Meikel Brandmeyer
On Tue, Apr 06, 2010 at 02:12:21PM -0600, Lee Hinman wrote:
> I'm having an interesting problem with a function that prints output
> similar to Clojure forms. When I call the function from a regular REPL
> there's no problem, but doing an ,el on the same line with VimClojure
> throws all kind of strange errors, it almost looks like it's trying to
> eval the output.
My suspicion is, that you output things bypassing *out* and *err*. This
will mess up things. I will investigate in how far I can rebind
System.out and System.err also. But first I have to understand how
nailgun handles this. It does there some magic hand waving.
Sincerely
Meikel
sergey-miryanov
I have no ideas what happens, but new vimclojure sometimes works
sometimes no.
My screen: http://img-fotki.yandex.ru/get/13/sergey-miryanov.2/0_3849c_ecfdabdf_orig
Sergey
Meikel Brandmeyer
On Apr 10, 5:59 pm, sergey-miryanov <sergey.mirya...@gmail.com> wrote:
> I have no ideas what happens, but new vimclojure sometimes works
> sometimes no.
> My screen:http://img-fotki.yandex.ru/get/13/sergey-miryanov.2/0_3849c_ecfdabdf_...
Does foo.txt contain binary data? Or other exotic characters?
Sincerely
Meikel
sergey miryanov
file in editor - I see a mess of characters).
> --
> You received this message because you are subscribed to the Google Groups "vimclojure" group.
> To post to this group, send email to vimcl...@googlegroups.com.
> To unsubscribe from this group, send email to vimclojure+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/vimclojure?hl=en.
>
>
Meikel Brandmeyer
On Apr 12, 2:56 pm, sergey miryanov <sergey.mirya...@gmail.com> wrote:
> Yes, it may contain string in UnicodeLittle encoding (If i look at
> file in editor - I see a mess of characters).
For now: please don't do that. Printing such data will even mess up
your terminal if you use a "normal" clojure repl. There is little
chance to detect binary data and protect against such things.
(Unescaped ", or NUL values). For different encodings, there could
probably some remedy, but this has not very high priority at the
moment.
Note, that this is only a concern when printing such data at the repl.
(def x (slurp "foo.txt")) should work perfectly well.
Sincerely
Meikel
sergey miryanov
Thank you for you tips, time and great tool!
Drew Vogel
One of the problems I had was that I could not figure out how to compile clojure-contrib with the pprint namespace AOT-compiled. This caused a stacktrace of which VC only reported the last-printed exception (regarding the NamespaceOfFile Var) that was a result of the pprint exception rather than the cause of it. I had to look at the VC source to find out how the namespace of the file is checked and then manually run the ng.exe client in the same way to get the entire stacktrace. I think the single biggest opportunity for improvement is to put the ng.exe error output in a split window, just like repl output. It's difficult to follow a stacktrace in the output of :messages and the way VC uses the vim messages system, the stacktraces often are not shown unless the user uses the :messages command.
Meikel Brandmeyer
On 7 Apr., 00:30, Meikel Brandmeyer <m...@kotka.de> wrote:
> My suspicion is, that you output things bypassing *out* and *err*. This
> will mess up things. I will investigate in how far I can rebind
> System.out and System.err also. But first I have to understand how
> nailgun handles this. It does there some magic hand waving.
fix the issue. Currently everything - stdout and stderr - go to one
stream as would be with the console. However, it can also be split.
However then the original order cannot easily be restored. I'm not
sure, what's better. Please test.
Note: you have to use the bundled nailgun server. If you embed
nailgun into your app, you have to set up the nailgun server
*before* clojure is loaded.
MarkSwanson
On Apr 4, 5:52 pm, Meikel Brandmeyer <m...@kotka.de> wrote:
> Dear adventurous Clojurians,
>
> I made some substantial changes to VimClojure. My hope is that things
> get more robust now, and if they break the diagnostics should be more
> usable.
Minor issue #1:
The migration error messages walked me through this:
1. let clj_paren_rainbow = 1 -> change to let vimclojure#ParenRainbow
= 1
2. when I did this, I got the error: clj_paren_rainbow is deprecated!
Use vimclojure#WantNailgun
I was confused because the solution to this is:
1. comment out: let vimclojure#ParenRainbow = 1 (not
clj_paren_rainbow)
2. let vimclojure#WantNailgun = 1
Perhaps a better error would be:
vimclojure#ParenRainbow is deprecated! Use vimclojure#WantNailgun
Minor issue #2:
1. vim test.clj
2. \sr
Fails.
3. exit vim
4. vim test.clj
5. \sr
Fails.
6. exit vim
7. vim test.clj
8. \sr
Works perfectly
When it fails :messages shows:
Vim(echoerr):Could not determine the Namespace of the file. ...Reason:
Vim(echoer
r):Couldn't execute Nail! {"value" : "test", "stdout" : "", "stderr" :
""}
It's strange that this happens randomly. Maybe vimclojure just needs
to retry automatically a couple of times?
MarkSwanson
> Fails.
> 6. exit vim
> 7. vim test.clj
> 8. \sr
> Works perfectly
>
> When it fails :messages shows:
> Vim(echoerr):Could not determine the Namespace of the file. ...Reason:
> Vim(echoer
> r):Couldn't execute Nail! {"value" : "test", "stdout" : "", "stderr" :
> ""}
>
> It's strange that this happens randomly. Maybe vimclojure just needs
> to retry automatically a couple of times?