On Tue, May 2, 2017 at 10:41 PM Ted Kremenek <kreme...@apple.com> wrote:
> On Apr 28, 2017, at 8:17 AM, Saleem Abdulrasool <compn...@compnerd.org> > wrote: > > Hi Ted, > > I think that what I'm proposing adding is quite small. It has a mirror > equivalent in the clang repository. > > > I thought about it more, and you convinced me. I’m fine with taking it. > Awesome! > Can you revise the description in PR 8610 to indicate what the PR is > actually for? It doesn’t provide a description. > Absolutely, will do. > > As to maintainence, I'm willing to take that on. I already maintain the > vim syntax support (I'm pretty confident that I've made the bulk of the > changes to it at this point). > > > Sounds good to me. > > > I'm not sure where the idea that vim needs its own repository came from. > In all my years using vim and packaging for various Linux distributions, > I've never seen such a requirement. > > > Interesting. I’m possibly crossing the streams with something else. > > > Personally, I think that splitting out the stdlib and the compiler would > be an even better thing (but that is a separate conversation). > > > It is — and because much of the language is defined in terms of the > Standard Library (e.g., “Int”) it’s hard to really test the compiler > without the Standard Library. They are very tightly coupled. > Yeah, I know that makes it pretty challenging. It's always made it difficult to write tests which don't depend on the stdlib. > So, I can't really protest against a different repository for the > support infrastructure. Could we create such a repo? > > > It’s an interesting discussion — although I’m not 100% certain what pieces > you think are “support infrastructure”. Are you referring specifically to > things like emacs and vim support? How about we take this change (modulo > the change in the PR to make it more descriptive), and spin a new thread on > splitting out a separate repository for support infrastructure. That said, > despite my earlier comments, I don’t think there is a big driver for that > right now unless we started to see those pieces start to significantly grow. > > WDYT? > I think integrating it into the main repo is probably the best choice given the size and complexity (it is really dwarfed by everything else, I think that gyb is more complicated than this piece). I'll go ahead and make the changes and hopefully we can get this merged soon :) > > Saleem > > On Thu, Apr 27, 2017 at 12:48 AM Ted Kremenek <kreme...@apple.com> wrote: > >> Hi Saleem, >> >> My apologies for the delay. >> >> Generally speaking, doesn't feel to me that these kinds of enhancements >> should be going into the 'swift' repository. We have some basic support >> files for editors in the repository, but largely those are there for >> historical reasons (largely convenience when the scope of the project was >> smaller) and their proper home should be probably reconsidered. To me the >> repository should really just be the compiler (and related infrastructure) >> and Standard Library sources — not a grab bag of anything related to Swift. >> >> That said, it raises the question of where should such things go. Should >> we have one repository at all for editor support stuff that is a peer to >> the 'swift' repository? Would such an approach even work with the package >> mechanisms that exists in various editors? I vaguely recall from a prior >> discussion something about vim and packages needing to be in their own >> repository. Note that I don't use vim myself, so I'm not familiar with >> what vim users do these days as far as packages. >> >> There is also a larger question of whether or not we need or should have >> "official" editor integration stuff in the main Swift repositories at all. >> I know it's a convenient place to put stuff, but the support model is not >> clear. Do we have an expectation that those files are relatively >> maintained and updated? And if so, by whom? The current files we do have >> there were added by folks working on the standard library or the compiler, >> and they use such files on a regular basis and because of that maintain >> them (at least for the use cases they care about). But I don't see a good >> path forward with the the 'utils' folder cluttered up with support files >> for all the different editors that are out there — which is why I think >> that ultimately even what we have today should probably move somewhere else. >> >> Ted >> >> > On Apr 24, 2017, at 4:07 PM, Saleem Abdulrasool <compn...@compnerd.org> >> wrote: >> > >> > Hi, >> > >> > Jordan asked me to check with you about adding a simple helper for >> integrating swift-format into vim since the repository hasn't really added >> any editor integration stuff previously. It's just a python wrapper for >> invoking swift-format (much like clang-format). >> > >> > It is on GitHub as PR8610. >> > >> > Thanks! >> > >> > -- >> > Saleem Abdulrasool >> > compnerd (at) compnerd (dot) org >> > -- > Saleem Abdulrasool > compnerd (at) compnerd (dot) org > > -- Saleem Abdulrasool compnerd (at) compnerd (dot) org
_______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
