Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Project status #73

Closed
Deraen opened this issue Jul 18, 2016 · 17 comments
Closed

Project status #73

Deraen opened this issue Jul 18, 2016 · 17 comments

Comments

@Deraen
Copy link
Contributor

Deraen commented Jul 18, 2016

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
Copy link
Owner

guns commented Jul 18, 2016

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
Copy link
Contributor Author

Deraen commented Jul 18, 2016

Great!

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

@benknoble
Copy link

benknoble commented Jan 19, 2020

@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
Copy link
Owner

guns commented Jan 19, 2020

@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
Copy link
Contributor Author

Deraen commented Jan 20, 2020

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
Copy link

axvr commented Sep 10, 2020

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
Copy link
Contributor Author

Deraen commented Sep 11, 2020

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
Copy link

axvr commented Sep 11, 2020

@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
Copy link
Contributor Author

Deraen commented Sep 11, 2020

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

@guns
Copy link
Owner

guns commented Sep 11, 2020

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
Copy link

axvr commented Sep 11, 2020

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
Copy link
Owner

guns commented Sep 11, 2020

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
Copy link

axvr commented Sep 11, 2020

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
Copy link
Contributor Author

Deraen commented Sep 11, 2020

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
Copy link
Owner

guns commented Sep 11, 2020

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.

@guns guns closed this as completed Sep 11, 2020
@Deraen
Copy link
Contributor Author

Deraen commented Sep 11, 2020

I've sent you invite to the @clojure-vim org, as you need permission the create repos on the target org to transfer the repo.

Once the repo is transfered, the repo can be renamed. Redirect should work even when repo is both transfered and renamed: https://github.community/t/how-long-does-github-forward-renamed-moved-repos/582

@axvr
Copy link

axvr commented Sep 19, 2020

Hi @guns, I don't want to rush you as I can understand how busy you must be, but we need the repo to be transferred if you want a redirect set up.


The steps to do a transfer are:

  1. Click the "settings" button at the top of this repo.
  2. Scroll to the bottom to the section labelled "danger zone".
  3. Click "transfer ownership".
  4. Enter @clojure-vim and the repo name.

This will move the repo to the @clojure-vim organisation with a redirect. Then we will rename the repo (which will set up another redirect).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants