Ruby/Perl beautifier

[geneg1]

I'd love to see Ruby/Rails support for Beautify. I just tried Ruby in SlickEdit (Mac) for the first time yesterday and when Beautify was greyed out I thought I might be doing something wrong... didn't even occur to me that Ruby beautification might not be supported yet.

I'm a little worried that there might be some fundamental issue with Ruby that makes beautification impractical or impossible, but I hope that you just haven't gotten to it yet.

[Clark]

I know it's not possible to reliably beautify perl but I'm not sure if ruby has the same problem. With perl, exact parsing is unknown until you execute the code.

[geneg1]

For what it's worth, there is a seemingly fairly simple Ruby source beautification script that has been floating around for years... http://neontology.com/beautiful-ruby-in-textmate. It's written in Ruby, but from what I can tell it doesn't do any fancy static analysis or anything that would preclude a similar  implementation in another language. I can't speak to the completeness of the beautification, but an 80% or 90% solution would still be much better than nothing.

[Clark]

The scary thing about an 80 or 90% solution is that the code might no longer be the same because you added or removed spaces from a string. What I don't know is if it's possible to detect all ambiguities. Then  code with no ambiguities would just work. For ambiguous code the user could be notified whether to proceed or whether to undo. A solution like this would be shippable.

[geneg1]

I agree that an ideal solution would detect multi-line strings (which are allowed in both Ruby and Perl, in several different syntactical flavors) and respect the existing whitespace at the beginning and end of each of those lines. However, I would make the point that any Ruby or Perl programmer using multi-line syntax (other than line-by-line concatenation) is almost certainly not depending on the whitespace being preserved at the beginning and end of each part of their string segments.

Having said that, there are probably exceptions and I can't argue with a safer approach. I don't know how SlickEdit handles beautification in other languages, but if it does any kind of stateful tokenization (rather than straight regex substitution) this would hopefully be possible.

[jwdonahue]

The scary thing about an 80 or 90% solution is that the code might no longer be the same because you added or removed spaces from a string. What I don't know is if it's possible to detect all ambiguities. Then  code with no ambiguities would just work. For ambiguous code the user could be notified whether to proceed or whether to undo. A solution like this would be shippable.

The file is read-only.  Just reload the buffer if the user wants to roll-back the beatification.  After reviewing the file, I might chose to check it out and modify it, at which point I should just be able to hit save.  I also use SlickEdit's versioning feature, so I have no problems with rolling a file back to a previous version if I should decide to abandon my edits.