<div dir="ltr">Sorry to resurrect an old thread! :)<div><br></div><div>I'd like to propose the following:</div><div><br></div><div>- 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.</div><div>- 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.</div><div>- We add a README to the swift/utils/vim directory, explaining its contents and how to install them. :)</div><div><br></div><div>I feel like this is a happy middle ground to what Ted K. proposed back in January. Thoughts?</div><div><br></div><div>- Brian Gesiak</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 7, 2016 at 10:02 PM, Ted kremenek via swift-dev <span dir="ltr"><<a href="mailto:swift-dev@swift.org" target="_blank">swift-dev@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div></div><div>Hi Keith,</div><div><br></div><div>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.</div><div><br></div><div>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 <b>swift</b>, <b>swift-package-manager</b>, etc., or should we take the route of having them hosted elsewhere and not directly part of the <a href="http://swift.org" target="_blank">Swift.org</a> 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).</div><div><br></div><div>The problem is where to draw the line on what is part of <a href="http://swift.org" target="_blank">Swift.org</a> 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 <b>swift</b> 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 <b>swift</b>.</div><div><br></div><div>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.</div><div><br></div><div>With this in mind, I propose an alternate direction (for which I encourage discussion):</div><div><br></div><div>- Remove the current support from vim from the <b>swift</b> repository.</div><div>- Encourage others to setup great vim support on GitHub.</div><div>- Call out such great vim support with links from the <b>swift</b> repository or <a href="http://swift.org" target="_blank">Swift.org</a> itself.</div><div><br></div><div>Thoughts? The same arguments here apply to editors like Emacs, Sublime Text, and so on.</div><div><br></div><div>Cheers,</div><div>Ted</div><div><div class="h5"><div><br></div><div>On Jan 3, 2016, at 8:26 PM, Keith Smiley <<a href="mailto:keithbsmiley@gmail.com" target="_blank">keithbsmiley@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div>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.<br><div class="gmail_quote"><div dir="ltr">On Sun, Jan 3, 2016 at 20:21 Ted kremenek <<a href="mailto:kremenek@apple.com" target="_blank">kremenek@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div></div><div>Hi Keith,</div><div><br></div><div>This makes complete sense. I can see why cloning a small self-contained repository would be ideal for plugin managers.</div><div><br></div><div>I'll talk about this with the core team, but I think this seems like a reasonable direction.</div><div><br></div><div>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.</div></div><div dir="auto"><div><br></div><div>Ted</div></div><div dir="auto"><div><br>On Jan 3, 2016, at 10:37 AM, Keith Smiley <<a href="mailto:keithbsmiley@gmail.com" target="_blank">keithbsmiley@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr"><span style="font-size:12.8px">Right there are 2 facets to the file hierarchy. The one covered in [2] is the</span><br style="font-size:12.8px"><span style="font-size:12.8px">standard structure vim expects when loading plugins. The need to be in a</span><br style="font-size:12.8px"><span style="font-size:12.8px">separate repo is for vim plugin managers.</span><br style="font-size:12.8px"><br style="font-size:12.8px"><span style="font-size:12.8px">The most popular plugin managers[0][1][2] work by either you cloning, or</span><br style="font-size:12.8px"><span style="font-size:12.8px">specifying a repo containing a plugin to load. This means you would use</span><br style="font-size:12.8px"><span style="font-size:12.8px">something like `apple/swift.vim` in the case of the plugin I'm hoping for. The</span><br style="font-size:12.8px"><span style="font-size:12.8px">plugin managers then add that cloned directory to vim's runtime path where it</span><br style="font-size:12.8px"><span style="font-size:12.8px">looks for the structure covered in [2] to be able to load the correct plugin</span><br style="font-size:12.8px"><span style="font-size:12.8px">files. If that structure doesn't exist at the root of the repo, it has no</span><br style="font-size:12.8px"><span style="font-size:12.8px">effect. Some of the plugin managers[2] do have the ability to specify the</span><br style="font-size:12.8px"><span style="font-size:12.8px">subdirectory of a repo, but even if that was something we were relying on,</span><br style="font-size:12.8px"><span style="font-size:12.8px">having to clone the entire `apple/swift` repo for less than ~10 small files is</span><br style="font-size:12.8px"><span style="font-size:12.8px">a lot of overhead.</span><br style="font-size:12.8px"><br style="font-size:12.8px"><span style="font-size:12.8px">Let me know if I need to elaborate more.</span><br style="font-size:12.8px"><br style="font-size:12.8px"><span style="font-size:12.8px">Thanks!</span><br style="font-size:12.8px"><br style="font-size:12.8px"><span style="font-size:12.8px">[0]: </span><a href="https://github.com/tpope/vim-pathogen" rel="noreferrer" style="font-size:12.8px" target="_blank">https://github.com/tpope/<wbr>vim-pathogen</a><br style="font-size:12.8px"><span style="font-size:12.8px">[1]: </span><a href="https://github.com/VundleVim/Vundle.vim" rel="noreferrer" style="font-size:12.8px" target="_blank">https://github.com/<wbr>VundleVim/Vundle.vim</a><br style="font-size:12.8px"><span style="font-size:12.8px">[2]: </span><a href="https://github.com/junegunn/vim-plug" rel="noreferrer" style="font-size:12.8px" target="_blank">https://github.com/<wbr>junegunn/vim-plug</a><br><div class="gmail_extra"><br clear="all"><div><div><div dir="ltr">--<br>Keith Smiley</div></div></div>
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<div><div><br>
On 01/02, Ted kremenek wrote:<br>
> Hi Keith,<br>
><br>
> 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.<br>
><br>
> Ted<br>
><br>
> > On Dec 31, 2015, at 12:09 PM, Keith Smiley via swift-dev <<a href="mailto:swift-dev@swift.org" target="_blank">swift-dev@swift.org</a>> wrote:<br>
> ><br>
> > Hey all,<br>
> ><br>
> > When swift was open sourced a few of us noticed that there was some existing<br>
> > vim highlighting support[0]. While it sounds like what's there now hasn't been<br>
> > kept up to date for a while[1], that brought up the question if there could<br>
> > ever be a dedicated repository for vim support under the apple github<br>
> > organization.<br>
> ><br>
> > Many vim plugin managers expect a specific folder structure[2] in order to<br>
> > work correctly. So the current nesting of the vim support in the main repo<br>
> > isn't ideal. I think it would be hugely beneficial to the members of the<br>
> > community who would prefer to use vim over any other editor, for there to be a<br>
> > first party repo similar to rust's[3].<br>
> ><br>
> > I'm not particularly suggesting that this plugin would be supported by the<br>
> > swift core team. As there are at least a few community swift vim plugins<br>
> > now[4][5] I would hope that as a community we would be willing and able to<br>
> > support this plguin. Personally I would love to be part of a unified effort<br>
> > towards better vim support for Swift!<br>
> ><br>
> ><br>
> > Thoughts? Thanks!<br>
> ><br>
> ><br>
> > [0]: <a href="https://github.com/apple/swift/tree/master/utils/vim" rel="noreferrer" target="_blank">https://github.com/apple/<wbr>swift/tree/master/utils/vim</a><br>
> > [1]: <a href="https://twitter.com/jckarter/status/672493376856391681" rel="noreferrer" target="_blank">https://twitter.com/jckarter/<wbr>status/672493376856391681</a><br>
> > [2]: <a href="https://robots.thoughtbot.com/writing-vim-syntax-plugins" rel="noreferrer" target="_blank">https://robots.thoughtbot.com/<wbr>writing-vim-syntax-plugins</a><br>
> > [3]: <a href="https://github.com/rust-lang/rust.vim" rel="noreferrer" target="_blank">https://github.com/rust-lang/<wbr>rust.vim</a><br>
> > [4]: <a href="https://github.com/keith/swift.vim" rel="noreferrer" target="_blank">https://github.com/keith/<wbr>swift.vim</a><br>
> > [5]: <a href="https://github.com/kballard/vim-swift" rel="noreferrer" target="_blank">https://github.com/kballard/<wbr>vim-swift</a><br>
> ><br>
> > --<br>
> > Keith Smiley<br>
> ><br>
> > ______________________________<wbr>_________________<br>
> > swift-dev mailing list<br>
> > <a href="mailto:swift-dev@swift.org" target="_blank">swift-dev@swift.org</a><br>
> > <a href="https://lists.swift.org/mailman/listinfo/swift-dev" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-dev</a><br>
</div></div></blockquote></div><br></div></div>
</div></blockquote></div></blockquote></div>
</div></blockquote>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=RwYb2GKd-2F4OO18dA6Iy-2B3LrStHfLgivaBZlWDE47E-2FKhptqx0I7jZeA19SlbqzzboKJZ-2FFvxLigpf23ln9eqOuC5XlCM27USqvat28TD8-2BIjPhZZADj1-2FljZq7Dkx3uDZIgL-2BRXkhwdPtpxtWDL-2BETarAAWbG6a9aENhF6TQYuMAKVtDqQT1a6Nb8xbFKTuLmucf-2BJxd0IQCDNblAgH7WA1XdhTjPo1u3pndlpaSo6E-3D" alt="" width="1" height="1" border="0" style="height:1px!important;width:1px!important;border-width:0!important;margin-top:0!important;margin-bottom:0!important;margin-right:0!important;margin-left:0!important;padding-top:0!important;padding-bottom:0!important;padding-right:0!important;padding-left:0!important">
</div></div></div>
<br>______________________________<wbr>_________________<br>
swift-dev mailing list<br>
<a href="mailto:swift-dev@swift.org">swift-dev@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-dev" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-dev</a><br>
<br></blockquote></div><br></div>