Sorry to resurrect an old thread! :) I'd like to propose the following:
Advertising
- We keep apple/swift's utils/vim, which will continue to provide syntax highlighting for SIL and .gyb (and maybe .swift) files -- in other words, file types that are relevant primarily to contributors to the apple/swift project. This resembles LLVM's utils/vim directory, which contains syntax highlighting plugins for LLVM IR (.ll) and TableGen (.td) files -- file types that mostly only LLVM contributors care about. - Vim plugins for people who use the Swift compiler, such as ones that integrate with Swift package manager, continue to be maintained outside of the Apple GitHub organization. - We add a README to the swift/utils/vim directory, explaining its contents and how to install them. :) I feel like this is a happy middle ground to what Ted K. proposed back in January. Thoughts? - Brian Gesiak On Thu, Jan 7, 2016 at 10:02 PM, Ted kremenek via swift-dev < swift-dev@swift.org> wrote: > Hi Keith, > > My apologies for the delayed response. I had a few conversations with > members of Swift Core and others about their thoughts here. We're treading > into new ground, so some of this we are figuring out as we go. > > Having great support for vim is something we want for the Swift project. > The same goes for the multitude of other editors and IDEs out there (both > open source and proprietary). The question that got brought up in my > conversations is whether or not we should look to host support for each of > those as sibling repositories in GitHub next to *swift*, > *swift-package-manager*, etc., or should we take the route of having them > hosted elsewhere and not directly part of the Swift.org <http://swift.org> > project? Taking the latter route could still mean acknowledging a > particular plugin for (say) vim is the recommended and maintained plugin > for Swift support for vim (or whatever editor). > > The problem is where to draw the line on what is part of Swift.org > <http://swift.org> and what is not. The entire Swift ecosystem does not > need to be part of the Swift project directly, nor conceivably could it > ever be. The existing vim support in the *swift* repository predates > open source. It was put there by a member of Apple's Swift team because he > was interested in using vim, and that was a natural place to put it. Now > that Swift is open source the repository goes beyond just serving the needs > of a relatively small number of individuals. There will be a natural > interest from the community at large to add editor support for other > popular editors, and the question is whether or not they should all be > positioned as sibling repositories to *swift*. > > My instinct at this point tells me "no", simply because we want an open > ecosystem for Swift stuff that goes beyond just what is in the core Swift > project. This allows the core Swift project to focus more on fostering an > ecosystem of tools, and provide a few core technologies like the compiler > and package manager, rather than focusing on providing everything in the > Swift universe. That said, even drawing this line is not always clear. > > With this in mind, I propose an alternate direction (for which I encourage > discussion): > > - Remove the current support from vim from the *swift* repository. > - Encourage others to setup great vim support on GitHub. > - Call out such great vim support with links from the *swift* repository > or Swift.org <http://swift.org> itself. > > Thoughts? The same arguments here apply to editors like Emacs, Sublime > Text, and so on. > > Cheers, > Ted > > On Jan 3, 2016, at 8:26 PM, Keith Smiley <keithbsmi...@gmail.com> wrote: > > Awesome thanks! I'd definitely be interested in helping maintain this > plugin. I can't speak for Kevin but I assume he would be as well. > On Sun, Jan 3, 2016 at 20:21 Ted kremenek <kreme...@apple.com> wrote: > >> Hi Keith, >> >> This makes complete sense. I can see why cloning a small self-contained >> repository would be ideal for plugin managers. >> >> I'll talk about this with the core team, but I think this seems like a >> reasonable direction. >> >> Incidentally, we would need one (or more) active maintainers for the vim >> plugin. Dmitri Gribenko was the one on Apple's Swift team most actively >> using vim, but I'd also be happy with somebody outside of Apple being the >> custodian of this plugin. >> >> Ted >> >> On Jan 3, 2016, at 10:37 AM, Keith Smiley <keithbsmi...@gmail.com> wrote: >> >> Right there are 2 facets to the file hierarchy. The one covered in [2] is >> the >> standard structure vim expects when loading plugins. The need to be in a >> separate repo is for vim plugin managers. >> >> The most popular plugin managers[0][1][2] work by either you cloning, or >> specifying a repo containing a plugin to load. This means you would use >> something like `apple/swift.vim` in the case of the plugin I'm hoping >> for. The >> plugin managers then add that cloned directory to vim's runtime path >> where it >> looks for the structure covered in [2] to be able to load the correct >> plugin >> files. If that structure doesn't exist at the root of the repo, it has no >> effect. Some of the plugin managers[2] do have the ability to specify the >> subdirectory of a repo, but even if that was something we were relying on, >> having to clone the entire `apple/swift` repo for less than ~10 small >> files is >> a lot of overhead. >> >> Let me know if I need to elaborate more. >> >> Thanks! >> >> [0]: https://github.com/tpope/vim-pathogen >> [1]: https://github.com/VundleVim/Vundle.vim >> [2]: https://github.com/junegunn/vim-plug >> >> -- >> Keith Smiley >> >>> >>> >>> On 01/02, Ted kremenek wrote: >>> > Hi Keith, >>> > >>> > I'm not a vim user, so I'm not certain how the nesting of the vim >>> support in the main repository is a problem. I looked at [2] and noticed a >>> requirement for a folder layout, but I didn't see anything obvious to >>> indicate that this would benefit from being in a separate repository. Can >>> you elucidate a bit more for my benefit? Note that I'm not saying there is >>> a benefit; I'm just lacking some context here to understand why a separate >>> repository is needed. If there is a clear benefit, this is something I'd >>> happily support and discuss with the rest of the Swift Core members. >>> > >>> > Ted >>> > >>> > > On Dec 31, 2015, at 12:09 PM, Keith Smiley via swift-dev < >>> swift-dev@swift.org> wrote: >>> > > >>> > > Hey all, >>> > > >>> > > When swift was open sourced a few of us noticed that there was some >>> existing >>> > > vim highlighting support[0]. While it sounds like what's there now >>> hasn't been >>> > > kept up to date for a while[1], that brought up the question if >>> there could >>> > > ever be a dedicated repository for vim support under the apple github >>> > > organization. >>> > > >>> > > Many vim plugin managers expect a specific folder structure[2] in >>> order to >>> > > work correctly. So the current nesting of the vim support in the >>> main repo >>> > > isn't ideal. I think it would be hugely beneficial to the members of >>> the >>> > > community who would prefer to use vim over any other editor, for >>> there to be a >>> > > first party repo similar to rust's[3]. >>> > > >>> > > I'm not particularly suggesting that this plugin would be supported >>> by the >>> > > swift core team. As there are at least a few community swift vim >>> plugins >>> > > now[4][5] I would hope that as a community we would be willing and >>> able to >>> > > support this plguin. Personally I would love to be part of a unified >>> effort >>> > > towards better vim support for Swift! >>> > > >>> > > >>> > > Thoughts? Thanks! >>> > > >>> > > >>> > > [0]: https://github.com/apple/swift/tree/master/utils/vim >>> > > [1]: https://twitter.com/jckarter/status/672493376856391681 >>> > > [2]: https://robots.thoughtbot.com/writing-vim-syntax-plugins >>> > > [3]: https://github.com/rust-lang/rust.vim >>> > > [4]: https://github.com/keith/swift.vim >>> > > [5]: https://github.com/kballard/vim-swift >>> > > >>> > > -- >>> > > Keith Smiley >>> > > >>> > > _______________________________________________ >>> > > swift-dev mailing list >>> > > swift-dev@swift.org >>> > > https://lists.swift.org/mailman/listinfo/swift-dev >>> >> >> > _______________________________________________ > swift-dev mailing list > swift-dev@swift.org > https://lists.swift.org/mailman/listinfo/swift-dev > >
_______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
