Project status

[Deraen]

Hi, @guns

Seems like this project has been quite inactive lately and there are several open PR's that would fix some minor problems.

I just created an clojure-vim Github organization which I hope will be home for some Vim Clojure plugins and where me and other Vim users can provide the plugins with active maintenance. What do you think about this?

There are at least two possibilities:

• I fork or copy the repo to the org, and manually merge/copy interesting PRs and issues. If you want, you could link the the new repo here.
• I'll invite you to the org and you can transfer the repo.

I don't have strong opinions and both should be as easy to implement.

[guns]

Seems like this project has been quite inactive lately

It's true! Let me see if I can inject some life into the project today, then let's continue this conversation.

Thanks for the shot in the arm!

[Deraen]

Great!

PS. I think #71 is worth a look and I think #69 is good :)

[benknoble]

@guns first, thanks for maintaining this project.

second, can we get a status update? There are a number of outstanding issues and PRs, at least one of which (#77) is pretty severe. I can't even hit enter just before the end of a long form (deftest ... ))))))|) without a very noticeable lag. (I believe this has more to do with the indent than the syntax, and I'm uploading a perf report here...)

I think we'd all appreciate it that performance branch gets merged, even if it's not perfect, just so we can see the gains.
clojure_indent.txt

EDIT I take it back; turning off syntax highlighting helped immensely with my 'hit enter' issue

[guns]

@benknoble Thank you for bringing my attention to this. I have been too busy to maintain this project, so it's definitely past time to pass on maintainership, just as @kotarak passed it on to me.

@Deraen Is the clojure-vim organization still active?

[Deraen]

Several of the organization members are active Clojure & Vim users and some projects have been updated recently. I'm not sure if I'd have time to work on this much myself, but I do have interest in improving this.

So yes, I think moving or forking to the organization would be a good idea.

[axvr]

Hi @guns and @Deraen, I would be interested in helping out (or even taking on the role of maintainer or co-maintainer).

I'm fairly new to Clojure (just started my first big project using it a few weeks ago, but have been playing around with it for almost a year) and have a good knowledge of Vim, Vimscript, Git and regular expressions.

I created and maintain several Vim plugins of my own, the most relevant to this project are: Zepl.vim; a small REPL integration plugin for Vim—which I use for Clojure—, and Org.vim; which provides syntax highlighting and folding for Org mode files. Both of these plugins were carefully designed to integrate well with Vim to feel like they're built-in.

In all my projects I strive for the highest level of code and documentation quality possible and take great care to ensure that I don't unintentionally break anything. However I am not against careful breakage of backwards compatibility or big changes.

Below I have included a list of some possible changes I would like to make to this plugin. (All of these would obviously be up for debate and none would be merged without proper feedback and testing.) If this is doesn't seem like a direction you would want the plugin to go, I completely understand and I'm fine if you reject my offer to help out.

Click here to view the list of changes I would like to make.

• Create additional file types for some Clojure project management files (e.g. EDN, Boot and Leiningen).

  These extra file types would make use of a lesser known feature described under :h 'filetype' which allows setting multiple file types for a file.

  As an example a syntax/lein.vim file could be created which adds the macro defproject. Then in ftdetect/clojure.vim I would add:

  autocmd FileType project.clj setfiletype clojure.lein

  Which first applies the Clojure file type then the Leiningen file type on top. I would also do the same for *.edn and {build,profile}.boot files as it would make this plugin more configurable.

• Code clean up and documentation overhaul.

  This would include the removal of old code such as the legacy VimClojure support.

• Rename project to "clojure.vim" (or "vim-clojure").

  To me "vim-clojure-static" makes it sound like it does more than it actually does, the rename would make it appear more official and be consistent with the names of other Vim filetype plugin repos. (GitHub automatically sets up redirects when a repo name is changed.)

• Replace syntax rule generation with hard-coded keywords to improve performance and maybe remove the g:clojure_syntax_keywords variable.

  This would be the preferred way instead:

  syntax keyword clojureFunction string/join string/replace
  syntax keyword clojureMacro defproject defcustom

• Replace several options with the standard Vim options.

  • g:clojure_fold: instead use autocmd! FileType clojure setlocal nofoldenable
  • g:clojure_align_subforms: instead use setlocal expandtab softtabstop=1 tabstop=1 shiftwidth=1 (this needs confirming.)

  Documentation would be added in place of these options to mention the alternatives I gave above.

• Create buffer-local versions (b:) of each of the configuration variables.

[Deraen]

Sounds good (though I'm also doubtful of align_subforms).

As @guns already said he'd be okay passing the maintainership, we could just create new repo which will be maintained. I think using Clojure-vim org would be good idea, but if you are going to be doing most work maintaining, you can choose where you want to have the repo.

[axvr]

@Deraen, I definitely agree with you that using the Clojure-vim organisation would be best plan as it would reduce the chance of (and make it easier to resolve) this situation happening again.

Regarding the possible changes I gave in my previous comment, I wouldn't remove any functionality without a decent alternative and on second thoughts I think clojure_align_subforms will be kept. I'm not yet sure if all those changes would be good ideas so they would only be merged if I consider them to be good, stable and no one objects to the change.

[Deraen]

@axvr I've sent you an invite to the organization.

[guns]

Thanks for stepping up to the plate @axvr.

Replace syntax rule generation with hard-coded keywords to improve performance and maybe remove the g:clojure_syntax_keywords variable.

This would be the preferred way instead:

syntax keyword clojureFunction string/join string/replace
syntax keyword clojureMacro defproject defcustom

The g:clojure_syntax_keywords variable is used by vim-clojure-highlight to offer dynamic highlighting from an attached REPL, so I don't think it should be removed.

If syntax highlighting is really a performance issue, the loop that calls syntax keyword on load is not likely the source of the problem. You could remove ~40% of the syntax keywords by removing the fully-qualified versions of the symbols from clojure.core. I'd start there before replacing generate.clj with a static list of keywords.

Rename project to "clojure.vim" (or "vim-clojure").

This project was originally called vim-clojure-runtime because it was a successor to Meikel Brandmeyer's VimClojure project, and because it contained Vim "runtime" files. vim-clojure-static was actually suggested by Tim Pope to differentiate it from Fireplace, which connects to Clojure REPLs. This is all in the past now, of course, so clojure.vim sounds good to me.

That said, "Cool URIs don't change", so I would like to make sure that any existing references to github.com/guns/vim-clojure-static do not become obsolete.

g:clojure_align_subforms: instead use setlocal expandtab softtabstop=1 tabstop=1 shiftwidth=1 (this needs confirming.)

The indent script is pretty subtle, so I suspect this may fall a little short.

[axvr]

Thanks for replying @guns, we've created a new repository at clojure-vim/clojure.vim so the old URI's won't break. (Maybe we could add a message to the old README with a link to the new repository?)

I did a search on GitHub earlier to see what projects were using g:clojure_syntax_keywords and indeed I did see that vim-clojure-highlight was using it (as well as another option) so I'll keep it around. I'll also keep g:clojure_align_subforms.

I am definitely going to try to remove the fully-qualified versions of the keywords. I was even thinking about possibly trying to highlight namespaces separately to functions and special forms (which is how Emacs does it) but I'll need to test it out first.

[guns]

Thanks for replying @guns, we've created a new repository at clojure-vim/clojure.vim so the old URI's won't break

Is there a way to set a Github repo to redirect to another so that users don't have to explicitly update their URLs to get new versions?

[axvr]

I don't think you can manually set up a redirect, but GitHub will automatically create redirects if you move a repository to another account or rename it, so we can try that if you'd rather. (If it doesn't work, we can move it back to minimise damage.)

https://github.blog/2013-05-16-repository-redirects-are-here/

[Deraen]

Transferring the repository from account to org or another account sets up redirect, and I think Git will mention the redirect and recommend the user updates remote address.

I usually prefer just keeping the old repository and mentioning the change in Readme, but I guess this repo is a bit different to Clojure packages as it is often used through the Git url.

[guns]

Alright, that's great. I'll redirect the repo this weekend. Good luck @Deraen and @axvr. I wish I was still programming in Clojure, but I'm very happy to transfer this project to folks with the ambition to further its development, just like Mikael Brandmeyer passed VimClojure to me years ago.

Please CC me on the email to vim_dev when you guys submit a new set of runtime files to Vim.