gfontenot / vim-xcode Goto Github PK
View Code? Open in Web Editor NEWWork with Xcode projects from within Vim
License: MIT License
Work with Xcode projects from within Vim
License: MIT License
When using Cocoapods you have a workspace where all the schemes of the pods and your own schemes exist.
Most of the time you don't want to run the pods schemes but only your own.
I would like to have an option to ignore the workspace for the list of your schemes.
If you don't like this option another way to fix this would be to look for Pods.xcodeproj and substract these schemes.
I'd try to implement this myself, if you'd be open to merge it 👍
Unfortunately, we're currently requiring users to build the app then run it as two different steps. This kinda sucks, and it'd be better if we could have some kind of build and run option.
Since we don't actually know when the build command finishes, it's probably best to generate the build command and the run command then send them both to the runner as build && run
.
Now that vim has first class async support, it would be awesome for this to be integrated into vim-xcode
This is starting to be a little more than a wrapper around xcodebuild
, and I think we're going to get further away from that. It seems like this plugin wants to be a way to work with Xcode projects themselves from within vim. For example, I'd really like to add a function for adding files to the Xcode index. That's way outside the scope of xcodebuild.
While editing a test it would be great to be able to run it and only it. Or to specify a test class or file to quickly test.
This will be tricky. If you look at facebooks xctool you will find they do this by creating a temporary scheme.
Right now, if I select a scheme, that selection is reset the next time I open the project. That kinda sucks. It might be better for user specified things like that to be cached in some way that we can check for when starting up.
Probably also means we should introduce some way to clear/reset the cache.
I'm getting further since #60 was fixed, but not quite all the way there yet. The application appears to successfully install in the simulator, but then fails to open:
An error was encountered processing the command (domain=FBSOpenApplicationErrorDomain, code=1):
The operation couldn’t be completed. (FBSOpenApplicationErrorDomain error 1.)
This could be related: http://stackoverflow.com/questions/31350957/fbsopenapplicationerrordomain-error-1. Something to do with environment variables on launch. I'll try take a look into this later.
I'm not sure if there's a way to limit the -complete=file
autocompletion to files matching a pattern but it seems like it'd be really nice to be able to only show files that end in .xcodeproj
.
I have an Xcode project, cd there. Then open it with vim .
because I want to try out this swell tool.
Anyway :Xbuild
fails on first try.
Error detected while processing function <SNR>33_build..<SNR>33_assert_project..<SNR>33_project_files:
line 1:
E118: Too many arguments for function: globpath
E15: Invalid expression: globpath(expand('.'), '*.xcodeproj', 0, 1)
Error detected while processing function <SNR>33_build..<SNR>33_assert_project..<SNR>33_workspace_files:
line 1:
E118: Too many arguments for function: globpath
E15: Invalid expression: globpath(expand('.'), '*.xcworkspace', 0, 1)
No Xcode project file found!
My guess is that this is because of spaces in the name of my project file. Not sure where to start debugging beyond just my guess.
Project name is "WM To Go.xcodeproj" (Also no there is no .xcworkspace, cocoapods is configured on the other branch)
We aren't escaping enough.
I succeeded install xcode.vim via Vundle in my first time. But for subsequent attempts, it pops out this error:
Error detected while processing ~/.vim/bundle/vim-xcode/plugin/xcode.vim:
line 55:
E122: Function <SNR>87_run already exists, add ! to replace it
However, I'm still able to use the plugin normally. It's just an annoying alert whenever vundle executed. Does anybody have this issue?
Right now, if there are multiple projects in the root directory, basically everything breaks. This is because we send all of the projects to the various commands that expect a project file instead of choosing just one.
Obviously, this isn't ideal. It'd be nice to figure out a nice way to select these from disk. Maybe default to the first, but let users specify one via a command (like we do with XSelectScheme
?)
Right now we're exposing commands like XOpen
and XBuild
and XTest
. However, fugitive exposes commands like Gw
and Gbrowse
. It seems like we should lowercase the second letter in our command names to follow suit.
Right now we just pick up the first available scheme, which isn't ideal. It'd be better if we could somehow let users choose which scheme to build.
I think there's also a thing that should work nicely with tmux, but in reality, this is just a glorified xcodebuild
flag generator. So if we just make the command to be run more dynamic (like in rspec.vim), we should be able to support all kinds of neat setups.
We're defaulting to --color --test
, but that's pretty prescriptive. I think it'd be better to default to no flags (or maybe just --color
) and let users customize the flags passed to xcpretty
via a configuration option.
Very possibly out of scope for this project, but one of the main advantages of working in Xcode is code completion. SourceKittenDaemon seems to provide the main pieces for getting this to work from inside of vim, which would make Xcode.vim an extremely compelling alternative to Xcode itself.
xcodebuild
now (I don't know when this was added) has the ability to run individual test bundles/classes/cases with a flag: -only-testing:Bundle[/Class[/Case]]
.We should be able to hook these up nicely.
Building the command building logic into vim-test itself probably doesn't make sense since there's plenty of intricacy involved and we'd end up re-implementing the bulk of vim-xcode. Likewise, vim-test has a lot of logic for parsing the bundle/class/case from a single file and building a flag (or list of flags) to pass to a test runner command accordingly that doesn't really make sense to duplicate here. That being said, we should be able expose the plumbing needed in vim-xcode and then end-users can add some local config in order to expose it to vim-test.
The gist would be to ship a test new runner integration with vim-xcode. This basically just means adding an autoload/test/xcode/xcode.vim
file to this plugin and following the extension steps laid out by vim-test. End-users would then need to add let test#custom_runners = {'Xcode': ['Xcode']}
to their local vimrc in order for vim-test to see our runner. We'd also need to open up some of the internals of vim-xcode via exposed functions (xcode#test_command()
, for example) so that we can access them from the vim-test integration.
Some issues I've run into this while testing that would need to be figured out (this list might change over time):
swift test
when they are both technically valid options? We might need to add something similar to the explicit runner selection config they have for Python and Go, but I'm not entirely sure how that would/should work since the only "official" runner is swiftpm.ArgoTests
. This is fine if you're testing the Argo-iOS
scheme because that happens to be the name of the test bundle in Xcode. But if you test the Argo-Mac
scheme, it fails with a semi cryptic error because there are no available tests. To make things worse, while you can run xcodebuild -list
to get a list of possible targets, there's really no way to 100% tell which target is a test target, and no way at all to tell which targets are linked to which schemes.Because we don't have anything setting -o pipefail
, if xcodebuild
fails, xcpretty
will still succeed, which isn't awesome. I don't know if this will be a huge issue, but it's probably worth noting.
If we can pass a file to XOpen
, it would mean we could do things like XOpen %
to open the current file in a new Xcode window, which would be useful. It would also mean we could do XOpen path/to/my/cool/Storyboard.storyboard
and get a new window with just that storyboard in it.
I haven't been able to successfully run in the simulator yet. Here's the output I'm seeing:
find: ftsopen: No such file or directory
2016-07-12 17:58:49.918 defaults[19684:4476942]
The domain/default pair of (/Info, CFBundleIdentifier) does not exist
I'm going to dig around in the code to see if I can work out what's going wrong.
When executing :Xbuild or :Xrun the output shows "Run Script" twice.
Press ENTER or type command to continue
▸ Building WM To Go/WM To Go [Debug]
▸ Check Dependencies
▸ Running script 'Run Script'
▸ Running script 'Run Script'
▸ Build Succeeded
com.walmart.delivery: 9573
Press ENTER or type command to continue
Not sure why this is, but I wanted to report it and help debug if needed.
Thanks.
I should be able to use AsyncRun as my runner right? (yay vim8.0!) I tried replacing the runner variable, but that made vim freeze up. Is there anything that would prevent this from happening you think?
ffs how is this so awful?
xcodebuild doesn't find implicit dependencies the same way Xcode finds implicit dependencies so it's super unreliable. This really fucking sucks, and means that users would either have to avoid implicit dependencies (ugh) or... I have no idea. I don't know how else to fix this.
Right now we're just showing the raw output, it might be nice to use a status window or some other neat trick so that vim doesn't lose focus. I have no idea how this would work.
So I'm not sure how difficult this might be, but what do you think about adding support for customizing test command arguments?
The two main use-cases I thought of are below.
set via g:xcodetest_arguments
https://medium.com/xcblog/wwdc18-xcode-10-in-action-f56e14c62d79
$ xcodebuild -project Xcode10-Demo.xcodeproj/ -scheme Xcode10-Demo -destination 'platform=iOS Simulator,OS=12.0,name=iPhone X' clean build test CODE_SIGN_IDENTITY="" CODE_SIGNING_REQUIRED=NO -parallel-testing-worker-count 4
https://stackoverflow.com/questions/35166214/running-individual-xctest-ui-unit-test-cases-for-ios-apps-from-the-command-li
set via g:xcodetest_arguments
or : Xtest -only-testing:TestBundle/TestSuite/TestCase
xcodebuild test -workspace <path> -scheme <name> -destination <specifier> -only-testing:TestBundle/TestSuite/TestCase
xcodebuild likes to spew lots of error messages about plugins. For example:
2015-09-10 16:33:24.329 xcodebuild[9442:73661] [MT] PluginLoading: Required plug-in compatibility UUID 0420B86A-AA43-4792-9ED0-6FE0F2B16A13 for plug-in at path '~/Library/Application Support/Developer/Shared/Xcode/Plug-ins/XcodeColors.xcplugin' not present in DVTPlugInCompatibilityUUIDs
2015-09-10 16:33:24.330 xcodebuild[9442:73661] [MT] PluginLoading: Required plug-in compatibility UUID 0420B86A-AA43-4792-9ED0-6FE0F2B16A13 for plug-in at path '~/Library/Application Support/Developer/Shared/Xcode/Plug-ins/FuzzyAutocomplete.xcplugin' not present in DVTPlugInCompatibilityUUIDs
2015-09-10 16:33:24.330 xcodebuild[9442:73661] Failed to load plugin at: /Users/ksmiley/Library/Application Support/Developer/Shared/Xcode/Plug-ins/FuzzyAutocomplete.xcplugin, skipping. Reason for failure: *** -[__NSPlaceholderDictionary initWithObjects:forKeys:count:]: attempt to insert nil object from objects[0]
It would probably be nice to silence this when using xcodebuild to load things like schemes by redirecting the output with something like: xcodebuild -list -project foo.xcodeproj 2>/dev/null
Right now, we have to get the scheme every time we do anything and it turns out, xcodebuild -list
is super slow. It'd be rad to cache this somewhere on disk so that we can get a kind of memoization thing going on.
We're hard coding a lot of iOS stuff in here right now, specifically with testing. We should be better about making that part dynamic and let people test OS X apps and frameworks.
This is also going to be important with watchOS/tvOS.
We aren't doing this correctly everywhere right now.
We don't have any tests right now, although it'd probably be nice to have some. At the very least we could have shellcheck run against the bin
directory to avoid issues like those in #55.
With #23, we're letting users explicitly set the scheme to test or build. That's fantastic, but it would be really great to add some autocompletion to improve the user experience.
This would probably entail changing the scheme finding script to return a list of schemes instead of a single scheme, and then caching that list.
the -sdk
flag apparently isn't super useful. We should switch to using -destination
Specifically:
-destination 'generic/platform=iOS'
-destination 'platform=iPhone Simulator,device=iPhone 6'
-destination 'platform=OS X'
(haven't tested this)For iOS projects, this should use the XBuild
command to build the project, then use simctl
(xcrun simctl
) to install the app.
# build
xcrun simctl install booted <path to built app>
xcrun simctl launch booted <app identifier> # this might be problematic
simctl usage:
Usage: simctl [--noxpc] [--set <set path>] <subcommand> ... | help [subcommand]
Command line utility to control the Simulator
For subcommands that require a <device> argument, you may specify a device UDID
or the special "booted" string which will cause simctl to pick a booted device.
If multiple devices are booted when the "booted" device is selected, simctl
will choose one of them.
Subcommands:
create Create a new device.
delete Delete a device or all unavailable devices.
pair Create a new watch / phone pair.
unpair Unpair a watch and phone phone.
erase Erase a device's contents and settings.
boot Boot a device.
shutdown Shutdown a device.
rename Rename a device.
getenv Print an environment variable from a running device.
openurl Open a URL in a device.
addphoto Add photos to the photo library of a device.
install Install an app on a device.
uninstall Uninstall an app from a device.
get_app_container Print the path of the intsalled app's container
launch Launch an application by identifier on a device.
spawn Spawn a process on a device.
list List available devices, device types, runtimes, or device pairs.
icloud_sync Trigger iCloud sync on a device.
help Prints the usage for a given subcommand.
I know this plugin does a great job as a wrapper over xcodebuild
. But do we have any approach on peaking at the runtime log while the app is running in the simulator?
Instead of autocompleting the simulator selection (see #8) to any simulator, it'd be nice to limit the selection to simulators supported by the specified scheme.
CORRESPONDING_SIMULATOR_PLATFORM_NAME
and SUPPORTED_PLATFORMS
hold some info about what simulators are supported by the selected scheme, that might be helpful?
if you have tmux misconfigured, xcrun instruments
isn't able to communicate with the simulator (?) properly. We should probably add a note in the async build section of the README and in the Xrun
section of the documentation about this.
/cc @sharplet
ideally, users would be able to (at least) pick an OS version to run against. This seems fairly important. We could (should) probably go further, and let users decide which simulator to run against.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.