Sorry to resurrect an old thread! :)

I'd like to propose the following:

- 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

Reply via email to