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
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 <compnerd@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
Hi Ted,
I think that what I'm proposing adding is quite small. It has a mirror
equivalent in the clang repository.
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).
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.
Personally, I think that splitting out the stdlib and the compiler would be
an even better thing (but that is a separate conversation). So, I can't
really protest against a different repository for the support
infrastructure. Could we create such a repo?
Saleem
On Thu, Apr 27, 2017 at 12:48 AM Ted Kremenek <kremenek@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 <compnerd@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
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.
Can you revise the description in PR 8610 to indicate what the PR is actually for? It doesn’t provide a description.
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.
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?
On Apr 28, 2017, at 8:17 AM, Saleem Abdulrasool <compnerd@compnerd.org> wrote:
Saleem
On Thu, Apr 27, 2017 at 12:48 AM Ted Kremenek <kremenek@apple.com <mailto:kremenek@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 <compnerd@compnerd.org <mailto:compnerd@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
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
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
>
> 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
On Tue, May 2, 2017 at 10:41 PM Ted Kremenek <kremenek@apple.com> wrote:
On Apr 28, 2017, at 8:17 AM, Saleem Abdulrasool <compnerd@compnerd.org> > wrote:
On Thu, Apr 27, 2017 at 12:48 AM Ted Kremenek <kremenek@apple.com> wrote:> On Apr 24, 2017, at 4:07 PM, Saleem Abdulrasool <compnerd@compnerd.org> >> wrote: