We started off using those convenience APIs from SourceKitten (huge thanks for SourceKitten, BTW) but ended up moving to our own solution — for this issue due to some performance issues, particularly in large files, and for interfacing with SourceKit in general because we wanted a little more control over request/response handling.
> On Mar 24, 2017, at 12:09 PM, Jean-Pierre Simard <j...@jpsim.com> wrote: > > I ended up writing some convenience APIs to perform these conversions along > with many other useful SourceKit<->Cocoa conversions like line+column, UTF-8, > UTF-16 and String.Index in SourceKitten. It's MIT-licensed so feel free to > grab the String extensions from the project yourself: > https://github.com/jpsim/SourceKitten/blob/master/Source/SourceKittenFramework/String+SourceKitten.swift > > That being said, you might have an easier time working with SourceKitten than > with with SourceKit directly, since it does a whole lot more, like > dynamically resolving+loading which SourceKit to use, caching expensive > operations, easier multi-threaded access, generating documentation, etc. > >> On Fri, 24 Mar 2017 at 10:59 Tyler Stromberg via swift-dev >> <swift-dev@swift.org> wrote: >> I'm currently working on integrating SourceKit with a macOS application. >> AppKit APIs (e.g. NSAttributedString, NSLayoutManager, etc) deal in terms of >> NSRange (UTF-16 code units?). SourceKit, however, deals in terms of integer >> offsets and lengths (UTF-8 code units?). Is there a more efficient or easier >> way to convert back and forth between the two other than doing the >> index(_:offsetBy:) -> samePosition(in:) dance? >> _______________________________________________ >> 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
