Xcode 8 Source Code Extension

[krzysztofzablocki]

How about we add a Xcode 8 Source Code Extension, we could use Sourcery to scan the code in the given file and feed the extension the meta type information.

That would mean that Xcode would now support context-aware snippets, which would make it significantly more powerful, even AppCode doesn't support those.

Also, I think it would increase the number of potential users of the Sourcery, because if we have that feature, even people that don't want to do code generation in their build phases can leverage and contribute to the tool.

[markohlebar]

There are a couple of problems there... The API for Xcode 8 Source Code Extension is still pretty limited. I think it could be pretty hard to determine the context of the source file you're looking at in Xcode as in:

• it's full path
• the project it is related to

However, if you could just feed Sourcery with text and make something out of that, it might work. I'll try to remember what we were brainstorming for Import extension, I think there was some stuff that could help. @clementpadovani @velyan

[krzysztofzablocki]

I was thinking of just feeding the text to the tool, since we usually need only local context for snippets, if we wanted full AST then we could write regular plugin but that requires people to unsign Xcode so better to limit it to native extension. Looking forward to hearing your experiences with it, I didn't had a chance to write the native extensions yet :)

[ilyapuchka]

If it will require to run sourcekitten then it will not work unfortunately as extensions do not let to call external processes. At least my attempts failed. Would be awesome to know that I'm wrong. Ilya Puchka Отправлено с iPhone

…

13 дек. 2016 г., в 9:40, Marko Hlebar ***@***.***> написал(а): There are a couple of problems there... The API for Xcode 8 Source Code Extension is still pretty limited. I think it could be pretty hard to determine the context of the source file you're looking at in Xcode as in: it's full path the project it is related to However, if you could just feed Sourcery with text and make something out of that, it might work. I'll try to remember what we were brainstorming for Import extension, I think there was some stuff that could help. @clementpadovani @velyan — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[krzysztofzablocki]

Do we have access to darwin notifications in extensions? If we do we could potentially use that to communicate between the app and extension, sourcery can run it's parsing on text as it does in tests

[ikesyo]

FYI jpsim/SourceKitten#271

[conradev]

Darwin notifications only have a single uint64_t state variable to communicate information. What does the sandbox profile for a source editor extension roughly look like?

[ilyapuchka]

So I've just made a simple prototype to work thanks to to the link from @ikesyo There are still few limitations, like extension not being provided with any kind of project info except currently opened file's content, or not being able to access any files out if it's container. But to make it work just for currently opened file will be possible in short time.

But there are few more things to solve here. Like accessing templates. As extension can not access anything outside it's container (which is ~/Library/Containers/extension.bundle.id/Data) it will be impossible to discover any template unless they are copied into this folder. This could be a simple task to solve just with a special cli command that would do that. When templates are copied extension can provide a menu item for each of them.

Going forward we could make an app (extension requires an app anyway) to manage templates, maybe even with a simple editor functionality.

And to make the extension really powerful we would need to give it access to Sourcery cache (again copying it to the container) that would be constantly updated in the background using some demon process maybe. Though this looks pretty complex and maybe it would be better to wait for the next version of Xcode if there would be any improvements for extensions from Apple.

The other way is to simply write a path to the sources to scan into extension container directory and scan them on each extension run using XPC service for Sourcery itself, instead of SourceKitten which I implemented now. This will also require to provide Sourcery functionality via framework ala SourceKittenFramework.

@krzysztofzablocki what do you think?

[krzysztofzablocki]

I'd reckon we should wait for next Xcode version and see what they provide there, rather than complicating the tool too much, especially now that we have inline generation