On Thu, Aug 21, 2014 at 04:43:58PM -0400, Benjamin R. Haskell wrote: > As with the Docker Zsh completion file that just got included in > upstream Zsh, I'd prefer that this doesn't make it into Vim "proper". > Including it in another project just makes changes harder to
From a distro package perspective, using zsh completion or vim syntax from contrib causes ownership issues (certainly on fedora and its downstreams, perhaps other distros too) as the dirs in which these files would be installed are owned by other packages. See: https://bugzilla.redhat.com/show_bug.cgi?id=1127570#c3 Including them in the main repo would solve that. If it's only Fedora's/RHEL's problem and if others don't want it included here, I'm cool with bugging the package maintainers to include this in their rpms. > propagate. Instead of taking just a pull request against the Docker > repo, a change goes through the idiosyncratic (and slower) Vim runtime > files change process (which apparently still involves emailing files > in the year 2014). The files that were upstreamed certainly won't be deleted from docker/contrib as per https://github.com/docker/docker/issues/7657 . I guess some people could take it upon themselves to periodically upstream changes from docker/contrib. > > I think the state of the Vim ecosystem would be much better if: > > 1. Vim shipped with (or at least advocated the use of) a reasonable > plugin/addon/package manager > - This would at least discourage the poor manageability of "Just > untar this into ~/.vim" > > 2. Vim didn't distribute (m/)any language-/tool-specific addons > - They contribute to the amount of maintenance work Bram has to do > - They detract from the amount of work that can be done on core Vim > - They can't be updated as easily as they can if developed independently > - They're subject to Vim's licensing (... kind of?). (At a > minimum, licensing has to be considered. In the separately-developed > scenario, it's simply not a concern.) > - They're weirdly tied to a single (point of failure) author. > > 3. Projects (like Docker) that have Vim files would set them up in a > way usable by (a) Vim plugin manager(s). > - "Via pathogen, the usual way..."¹ seems a bit glib/useless > > #'s 1 and 2 are obviously out-of-scope for this Docker-specific > request. But #3 should be easily achievable, AFAICT: > > My preferred plugin manager, Vundle², for example, makes installing > the Docker syntax files as simple³ as adding one of the following to > `.vimrc` or equivalent: > > ``` > " if installing from scratch: > Plugin 'docker/docker', {'rtp': 'contrib/syntax/vim/'} > > " if you already have `docker/docker` checked out: > Plugin 'file:///home/bhaskell/git/docker/contrib/syntax/vim' > ``` Haven't used plugin managers myself, and I'll be sure to try them out, but I think the aforementioned file/dir ownership issues would be applicable in this case too. Correct me if I'm wrong. > > -- > Best, > Ben > > ¹: > https://github.com/docker/docker/tree/cb47ddd968747091fd1b3d408dd36c4c2086e69f/contrib/syntax/vim#installation > ²: https://github.com/gmarik/Vundle.vim > ³: "simple", and in this case, amazingly inefficient (since it clones > the whole Docker repo). "simple" != "perfect". With Pathogen, on the > other hand, you could download an archive of just that > `contrib/syntax/vim/` directory. But that's an extra (manual!) step. Thanks, -- Lokesh
pgpDfZyo8EJPG.pgp
Description: PGP signature
