Open amerlyq opened 8 years ago
many thanks but I disagree. With near thousand starts I bet ag.vim is a stable and useful plugin on it's actual shape for many people. @amerlyq let's see if we can organize my fork and persuade @rking about its features, and then let's think on next step.
I will stick on upstream plugin as much as I can, so changing
Plugin rking/ag.vim
to
Plugin albfan/ag.vim
must be an acceptable annoyance meanwhile
I haven't heard from @rking in awhile, and as far as I know I'm the only other maintainer (not sure how to check that) on rking/ag.vim. I've been meaning to get to the issues, but haven't found much extra time. I'm hoping to get to them more in the beginning of the new year, and we can discuss merging some forks then if you like.
Some other things this project needs (imo):
Other than that we should discuss the other forks and see if we can make everyone happy without adding too much code :smile:.
Love the idea: lot of talk abd few code changes possible. That implies a lot of code review and some better comunication channel, so I added a room in
https://gitter.im/albfan/ag.vim
And added all of us. Let's see how it goes.
Alright, as for necessities, described in initial post on this thread. I have reviewed all currently active forks, which have diverged/stagnated -- therefore will not be merged eventually, and listed relevant differences in albfan#53 to merge them by ourself. Also, there was noticed rather often tendency to fork only to change buffer mappings. Therefore, mechanics to change them will be provided, derived from #76. I hope such improvement will lessen quantity of minor forks, at least in future.
Hmm... I'm not sure what to do here. I'd like to revive this discussion, but there's one thing I'm still confused about. I'm guessing @rking owns the copyright on the changes on this project since it was forked from https://github.com/mileszs/ack.vim, and various other maintainers own the copyright on some code. Because of this, I'm not sure who (other than @rking) is allowed to license this project.
I'm not a laywer, so it'd be nice to get some legal advice on this before adding a license and merging things. As a side note: ack.vim added a license to their project at the start of this year.
Well, then there's two sides for this issue. One is to contact @rking to get permissions to fork or change this codebase. and second (most important for me) is decide what features are interesting to merge (test suite, aggroup, api changes, support for X search native tool, compatibility with nvim)
I guess we can discuss second point meanwhile first point is being resolved.
@rking hasn't had any activity on GitHub in nearly two years and the website that is listed in the user's profile yields a DNS error. I'm guessing that this person is no longer around.
Hey everyone. I'm really sorry but there are a couple of issues that mean I'll be deprecating this repo:
let g:ackprg = 'ag --vimgrep --smart-case'
cnoreabbrev ag Ack
cnoreabbrev aG Ack
cnoreabbrev Ag Ack
cnoreabbrev AG Ack
Seems all we want to share a great ag vim plugin, but we are stagnated on this repo.
I'm pretty comfortable with this little mess, but would love to share it with others.
Count on me to collaborate in any fork about ag. As you suggest I will try to reopen an issue about group option on mileszs/ack.vim
https://github.com/mileszs/ack.vim/issues/94#issuecomment-227089639
I'm not a laywer, so it'd be nice to get some legal advice on this before adding a license and merging things. As a side note: ack.vim added a license to their project at the start of this year.
I just wanted to clarify FWIW: the issue referenced there was not when the license was actually added, I couldn't have made that decision unilaterally myself without clearing it with previous contributors. I just added an explicit complete LICENSE
file for distribution packaging policy. ack.vim was licensed under the Vim license since its first commit.
Unfortunately ag.vim seems to have removed mention of any license from the help doc file at some point after the fork, thus some contributions have happened under no clear license. That is indeed an unfortunate sticky situation 😦
I'm happy to discuss co-maintainers on ack.vim, I'd invite you to open a new issue on the repo about collaboration to start discussion. It might take a bit of time to get help from Miles to make admin changes happen, but he's generally been responsive. I'm sure we can set up Gitter for the project if that makes discussion easier, perhaps even move the project to an organization so it's easier to share management responsibilities.
I will note: improving existing behavior and fixing bugs is most welcome, but ack.vim began as a light wrapper that showed how elegantly Vim's existing grep functionality could be extended, and I personally do not want to see it grow a lot of new features now, in fact after some time working on its maintenance I've developed the philosophy that it should have fewer features. I'm leaning toward using vim-grepper myself because it's very close to a more modular approach I wanted to take if I had made a fresh start before that project did. That said, if the community loudly demands such new features, I'm willing to yield, but I may be more likely to step down at that point if there is new blood helping to maintain the project. For now I have no intention to do that while I'm the only active maintainer.
Anyway, we can continue this sort of conversation in ack.vim's project context if that's a direction people want to pursue.
@ches, @albfan: thanks for your comments. I tend to agree that smaller plugins are better. I might open a few PRs, but for the most part using ag with ack.vim hasn't been a problem. I guess we'll see what kind of features people want going forward. Forking again is always an option.
I would like to ask you to share write/merge permissions to this repository with somebody interested in from the community. It would allow to boost currently stagnated development of this plugin. Because your participation in project becomes less and less observable, amount of issues and forks exponentially increases. We need someone to put this in order and quickly respond to requests.
Of course, you could say, fork it and develop by itself. But. Everybody, and newbies especially, chooses trunk with most stars, which currently is yours. There are no distinguishable chances for any other fork to get that many stars in nearest future to outweight this.
I propose @albfan as co-maintainer, if he agrees. Otherwise, anybody ready to tidy up issues list and revise forks will do.