Eliminate dependency on VimClojure

[brandonbloom]

VimClojure has been serving me quite well for syntax highlighting, indentation, etc, but I never did get the Nailgun thing working correctly. Foreplay's nRepl integration has been working splendidly so far.

Would be nice to halve the number of Clojure-related plugins I've got installed. In that vein, maybe @kotarak is interested in contributing the static parts of VimClojure to ship as part of the standard vim distribution?

[tpope]

Hi @kotarak, sorry you got dragged into this so awkwardly.

I like VimClojure's static support but had different ideas about how the dynamic stuff should work, which is why I wrote foreplay.vim. I'm with @brandonbloom in that it would be nice if we could separate the two, so that the former could some day ship with Vim. I see you used to ship "Gorilla" separately. What was the reason you combined them?

[kotarak]

VimClojure is all MIT licensed. Feel free to use.

Many changes, eg. when adding a feature, required changes on the front- and on the backend. It made sense to keep them together. What you are talking about are probably the purely static files. Up to now there was no need to separate them out into a completely separate project, because there a) was no other consumer and b) the interactive server part is all opt-in.

[tpope]

Good to hear, @kotarak. It's not high on my priorities, but at some point I will likely look into teasing them apart.

[guns]

@kotarak

I've extracted the static syntax, indent, and ftplugin bits from VimClojure into vim-clojure-static:

https://github.com/guns/vim-clojure-static

The scripts are now completely standalone, and work independently of VimClojure. The syntax file is designed to work with external rainbow parentheses scripts (like https://github.com/kien/rainbow_parentheses.vim ) so this introduces a slight incompatibility with VimClojure's indent script, which assumes the existence of the clojureParen\d syntax group. I didn't think this was a large loss, since users interested in VimClojure are advised to install VimClojure and avoid vim-clojure-static. This is also an easy change to make in VimClojure if you like.

Here's a diff of VimClojure and vim-clojure-static runtime files: https://gist.github.com/4275458

Note that the builtin syntax groups are generated by a clojure function: https://github.com/guns/vim-clojure-static/blob/master/genkeywords.clj

@tpope mentioned that it should be possible to have Vim ship with static Clojure runtime files. Would you mind if I submitted these to Bram?

[kotarak]

@guns

Thanks for untangling that. How do I base VimClojure (interactive part) on that? By copying over snapshots? (Vim is missing some dependency management here.)

I'm not sure that the current forking and splitting will increase the user experience for plugin consumers.

[kotarak]

@guns

BTW: go ahead and submit the runtime files for inclusion in Vim proper.

[guns]

On Thu, Dec 13, 2012 at 04:48:09AM -0800, Meikel Brandmeyer wrote:

@guns

Thanks for untangling that. How do I base VimClojure (interactive part) on that? By copying over snapshots? (Vim is missing some dependency management here.)

The goal would be for VimClojure to be totally decoupled from the runtime files, just like any other Clojure plugin.

Actually, I'm a little surprised! I assumed that you would want to keep control of the upstream, and that I would apply the patches as you update (and send patches up when appropriate).

Anyway, decoupling VimClojure from the runtime files is not difficult at all; it's literally as simple as deleting the parts that have been extracted (along with the util functions that were used only in the indent and syntax scripts), then moving the interactive bits into the autoload and plugin scripts.

The only necessary dependency that the interactive portion has on the runtime files is the syntax group names for Dynamic highlighting. I was aware of this and made sure not to touch the syntax group names for clojureVariable, clojureMacro, and clojureFunc, so this feature should not be affected.

However, I did remove the clojureSexpLevel\d and clojureParen\d groups, along with the rainbow parentheses feature, because kien's rainbow_parentheses.vim script is both more general and extensible than VimClojure's, and thus I can have the same effect in my scheme files as in my clojure files without separate configuration.

I can certainly imagine that you like your implementation better than kien's, so VimClojure could easily re-add its rainbow paren implementation and clobber the paren syntax groups. We can do this without breaking the syntax or indent scripts, because both have been refactored to not depend on the paren syntax group name (which was not true before).

Or if all of this is a big pain, VimClojure can simply continue to ship as is, provide it's own runtime files as before, and happily ignore whatever the system may be providing with no adverse consequences.

I'm not sure that the current forking and splitting will increase the user experience for plugin consumers.

It is widely regarded that your Clojure syntax and indent files are the best by a wide margin. I think it would be a big win for vim clojurists to have your files in the distribution.

Also, there are many people like me who are trying to construct their own Clojure workflows by using bits and pieces from different sources. Recently, Tamas Kovacs extracted paredit.vim from slimv into its own repo, which has simplified the process of updating that script for people who don't want to use slimv.

Similarly, there is a lot of demand for an extraction of your runtime files into its own repository, so that grabbing the latest version is as easy as a git or hg pull away. Currently, to update the vim runtime files from source, I have a script that creates the vim zipfile via gradle vimZip, then extracts it into my pathogen vim/bundle directory. I think lessening this kind of friction will allow people to embrace Vim as a great place to write Clojure.

Finally, I would argue that decoupling the syntax, indent, and interactive bits in this fashion will lead to better code, and is also very much in the spirit of Clojure.

My gut feelings on the matter is that this could be a big win for VimClojure as well; there's nothing like deleting code! Like I mentioned before, I did not expect you to feel the same way, so I have every intention of playing faithful downstream consumer if that is what you desire.

[kotarak]

@guns

I think this is too much copying going around. There could be vim-clojure-static which everyone uses and where changes are collected. From time to time, an update is pushed from there to Vim proper.

I will remove the static files from VimClojure. There is no need in duplication. I planned some split into a vimclojure “group” of repositories anyway, but now that there is vim-clojure-static that can be kept as well.

I don't have a particular preference about the rainbow parens. I simply stole things from the scheme plugin, I believe. If there is something more general, then that's ok. We just should point people there.

BTW: There is no need for using the vimZip task. Just symlink the vim subdirectory in your bundle directory. Or copy it over (eg. on Windows). vimZip is just for distribution on vim.org.

[guns]

I will remove the static files from VimClojure. There is no need in duplication. I planned some split into a vimclojure “group” of repositories anyway, but now that there is vim-clojure-static that can be kept as well.

I am sorry to have forced your hand. I will contact you offline to coordinate the changes.

I don't have a particular preference about the rainbow parens. I simply stole things from the scheme plugin, I believe. If there is something more general, then that's ok. We just should point people there.

I think that's great. Like I mentioned, removing the rainbow parens support also presented an opportunity to remove assumptions about the paren group names, which allows the indent script to be independent of the syntax script.

BTW: There is no need for using the vimZip task. Just symlink the vim subdirectory in your bundle directory. Or copy it over (eg. on Windows). vimZip is just for distribution on vim.org.

Sorry about that! I think I convinced myself it was the best way because simply copying the vim subdir did not copy the README and LICENSE files. I wanted to be sure to adhere to the license.

[tpope]

@guns you beat me to it. Nice work, all.