Refactor mode for Swift

[nicklanasa]

I've been trying to start a refactoring mode for Swift that would work something like js2r-refactor by Magnar. I keep thinking that Swift-mode would need to be updated to find nodes, etc. Just wanted to know what any of you thought about this mode and if anybody would like to help.

Thanks!

[ryanprior]

I don't think that swift-mode works like js2-mode. Which is to say, js2-mode implements a complete Javascript parser in order to allow accurate highlighting, refactoring, etc.

Are you proposing creating a full Swift parser in elisp?

[nicklanasa]

@ryanprior I guess that would be the best route. Having a Swift parser would definitely help build something like js2-mode and a refactor mode. Maybe utilize something in Apple's new Swift repos?

[ryanprior]

irony-mode has a server that uses llvm's libclang to generate accurate data for auto-completion, documentation, etc for C, C++, and Objective-C.

Swift also uses llvm, so we might be able to extend irony to cover Swift. It would be nice to have a single platform that can understand both Objective-C and Swift.

irony doesn't have any facilities for refactoring yet, but if we built them for Swift then it would be that much easier to extend them to irony's other languages.

Another possible avenue would be to extend Semantic to support Swift. That could be done directly in elisp. However, Semantic tends to be fairly slow, and we would have to track changes in upstream Swift language and reflect them in our own implementation.

The benefit is that Semantic already has various kinds of refactoring tools and provides a great platform for building more.

There is a thread that connects these two approaches: in 2013 there was some work done to provide the information Semantic needs using irony's server as a backend.

js2-refactor uses another approach entirely, which is to write a parser in elisp from scratch. I wouldn't go that route personally, but I'm interested to hear your thoughts and definitely want to build some great Emacs tooling around Swift.

[nicklanasa]

@ryanprior I definitely think that using irony-mode is the route to go since it already has support for Objective-C which it's going away anytime soon and it's just an extra benefit.

The refactoring bit will come easier once we have a parser that understands Swift. So, I think working on extending irony to support Swift is the first battle. I've never used irony so I would first have to understand how it all works.

Any tips or places to start with irony that would help me understand exactly how the auto-completion, documentation, etc is handled?

Also, I don't know if you saw but auto-completion for Swift is already sort of working with company-sourcekit so we might be able to use it as a reference.

Also, I do think that building off of Swift-mode might be wise since it already has support for some stuff like syntax highlighting, some flycheck support, etc.

Either way, let me know your thoughts.

[ryanprior]

I'd start with the user documentation for irony-mode and irony-eldoc which are both pretty good, then get into the source code. There are two parts: the server to generate the data, written in C++ using libclang, and the client written in elisp which consumes the data.

To make a comparison to company-sourcekit, the irony server is like sourcekit and the client uses company and eldoc.

Although I use irony-mode and I've read some of the client elisp code, I don't know anything about the irony server. I also don't know anything about the swift toolchain internals and what they provide that's comparable to libclang.

So the first steps are ask the irony maintainers to see if they have opinions, read more into how irony's server works, and learn about Swift's toolchain.

[nicklanasa]

@ryanprior Thanks for the response, I'll follow the issue opened up for irony-mode and hopefully we can start getting something going soon.