RubyMotion support

We're currently discussing this internally. It's quite likely that we will support MacRuby (and RubyMotion specifically), but we don't have any timeframe for this yet.

Hello Benoit,

I've created feature request for RubyMotion support, feel free to vote for it and track it's progress

Thanks Dennis. The link you gave to the feature request is broken. I believe it should be: http://youtrack.jetbrains.com/issue/RUBY-11039

Thanks, I look forward to the merging of AppCode and RubyMine for iOS development in a combination of ObjectiveC and Ruby. This will be a great product.

Thank you for correcting, I've fixed link in my message.

Hm, this doesn't look promising to me. It is just the argument syntax and method "duplicates" which cause major complications.
Could you make a "try at your own risk" dev-plugin for the starters?
Or maybe open-source your ruby plugin so that the community could fix it?

I don't know why this doesn't look promising. :) Obviously we can't change our near-term development plans immediately as every new technology gets announced, but RubyMotion/MacRuby support is something we're seriously considering.

The main problem is not the syntax, but rather implementing code completion for Cocoa methods in Ruby code.
The Ruby plugin and RubyMine share the same codebase. RubyMine is a commercial product, and we have no intentions of open-sourcing it.

I actually think it's encouraging to hear that JetBrains is already discussing what it would take to do this only one day after RubyMotion was announced. Considering none of us knew about RubyMotion six days ago, and considering there isn't another product that offers the sort of advanced auto-completion and refactoring support that RubyMine does, it's probably best if we cut the RubyMine team some slack. I continue to get emails multiple times a day from people voting for RubyMotion support in RubyMine. If there's a real demand for it, I'm sure JetBrains will come through.

The other thing I'm sure JetBrains has to consider is how this fits in with AppCode. RubyMine seems to be focused on the Rails web development market while a completely separate product, AppCode, is targeting the iOS market. While the language of RubyMotion matches up with RubyMine, the market really matches up more with the new AppCode product.

I'm not sure what the right solution is, but what'd be really neat is if we could 1) code in Ruby, 2) get RubyMine's Ruby editing and refactoring, 3) get AppCode-like integration with Interface Builder. If you could add autocomplete and Interface Builder integration features for RubyMotion users, you'd suddenly make that platform a lot more attractive. For me, I don't really care whether those features are packaged into RubyMine or into AppCode as long as I had a product that let me build iOS apps in Ruby with excellent autocomplete and refactoring support, and maybe even Interface Builder support (though I could see that needing to come in a later version), I'd' be very interested.

I am sorry for my pessimistic evaluation. I just thought that your sentence meant "we might add RubyMotion support in a half a year". :)

I have some partial solution for code completion by generating class stubs from bridgesupport-files. It is far from ideal but it gives some hints. I believe one can make the stubs even better in near future. I was also considering writing a plugin for RubyMine to deal with the syntax, but this requires some time for a person having no experience in this matter. Having no source code for the Ruby plugin, it is probably unrealistic.

As I can see, RubyMotion support in TextMate and Redcar is being actively implemented, so one could use them in the meantime. I haven't seen anyone considering tweaking Radrails but this seems possible since the code is open https://github.com/aptana/radrails However, RubyMine is my favorite Ruby IDE and will probably always be.

What is your near-time development plans and how soon can you put RubyMotion in them?

Concerning RubyMotion and Interface Builder, you may be interested in http://ianp.org/2012/05/07/rubymotion-and-interface-builder/

Actually "half a year" is a fairly good estimate for when this functionality might be released. Right now we're working on RubyMine 4.5, which will be released as EAP very soon, and which will not include any MacRuby or RubyMotion support.

Thanks Andrei! I wasn't aware of this option for working with interface builder. Nor was I aware of the work being done on textmate and redcar to support RubyMotion.

So, you make a good point--if the open source guys have been able to start adding basic autocomplete (and even interface builder) support this quickly, it'd be nice to hear from JetBrains what their plans are and how long it would take to incorporate similar features into their products.

AppCode is built very closely around the XCode project model, which is completely irrelevant in the case of RubyMotion. I would expect that the RubyMotion support will become a feature of RubyMine, not AppCode. Of course, that doesn't block us from implementing Interface Builder integration too.

You say the main problem is not the syntax. Maybe so for complete support of RubyMotion in RubyMine. However, lack of syntax support is stopping anyone from using RubyMine with RubyMotion in the interrum. If you reformat code with the named parameter syntax the code will be broken by RubyMine. Fixing that would represent an immediate tangible bennefit to RubyMine/RubyMotion users.

For example...

    def application(application, didFinishLaunchingWithOptions:launchOptions)

The MacRuby syntax for hashes will be supported in RubyMine 4.5.

Wonderful! Thanks!

Please also add support for RubyMotion named parameters indentation. I wish they had a closer look to those in Objective-C (meaning, parameters must be aligned by colon rather than parameter name).

As is :
                    def tableView(tableView,
                         didSelectRowAtIndexPath:indexPath)



To be :
                    def tableView(tableView,
  didSelectRowAtIndexPath:indexPath)
=========================================



The same thing refers to invocations :
As is :

UIView.animateWithDuration(2,
    delay: 1,
    options: UIViewAnimationOptionCurveLinear,
    animations: lambda {
       @view.frame = [@points[@current_index], [100, 100]]
    }, completion:lambda {|finished|
      self.animate_to_next_point
    })

UIView.animateWithDuration( 2,
                     delay: 1,
                   options: UIViewAnimationOptionCurveLinear,
                animations: lambda { @view.frame = [@points[@current_index], [100, 100]] }, 

                completion:lambda {|finished| self.animate_to_next_point })