My tweet was inflammatory, so excuse me (I was actually mad at Travis and vented about this instead).
However, I think deeper integration with SourceKit formatting and Xcode would be beneficial, though I don’t know how much useful discussion about this can take place on the lists given that it’s really up to the IDE team to implement this feature. ~Robert Widmann > On Jan 17, 2017, at 12:25 PM, Daniel Martín via swift-dev > <swift-dev@swift.org> wrote: > > Hi, all: > > I've been planning the implementation of per-project code style support for > Swift. Hopefully, if implemented correctly, this tweet would not be true > anymore: https://twitter.com/CodaFi_/status/821142027077238784 > > As I understand it, right now we have two possible kind of clients for > formatting Swift code (both are exercising code inside the swiftIDE library): > > - Xcode: IDELanguageSupportUI, which is a plugin installed by default with > Xcode, is responsible for sending a message to SourceKit with the > "format.usetabs", "format.indentwidth", "format.tabwidth" parameters, among > others. SwiftIDE simply formats the region and updates the buffer. I suppose > other third party editors also use this mechanism. > > - Swift-format: This little internal tool only uses a single function from > Formatting.cpp, passing the desired format options as a parameter. > > In order to support different code styles per project, we need to make, at > least, the following changes: > > - Create some factory methods for the CodeFormatOptions struct, one for each > supported style (initially, only "Default", or "Apple", ie. no tabs, 4 > spaces, no case label indentation in switch statements). > > - Add support for reading an optional .swift-format file inside the current > directory. This file would be a simple YAML file with key-value pairs like > this: > > ---- .swift-format ---- > > Style: Apple > > IndentWidth: 2 > > Does it make sense? I'll try to maintain the same SourceKit interface so that > Xcode and other editors don't break and at the same time it's easy for them > to opt-in this feature. > > Opinions? > > Thanks, > > Daniel Martín > > _______________________________________________ > 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
