Hi,
I don't know whether this was reported before.
The following Ruby Script has a misbehaviour (please consider [1] and [2] as markers :):
puts "Here's 1 +[1] 1: #{ 1 +[2] 1}"
If the Caret is at position [1], Apple-R runs the program inside the ruby interpreter. If the Caret is at position [2], the default Run- command (Build in X-Code is used).
This is because #{...} is scoped as embedded Ruby source, which is explicitely filtered for the Run-Command. I didn't patch it, as I don't know which way to go (changing the scope or changing the scope selector for the command). But I hope the bundle maintainer can sort that out in a second :).
Greetings Skade
On Nov 12, 2007, at 7:29 AM, Florian Gilcher wrote:
The following Ruby Script has a misbehaviour (please consider [1] and [2] as markers :):
puts "Here's 1 +[1] 1: #{ 1 +[2] 1}"
If the Caret is at position [1], Apple-R runs the program inside the ruby interpreter. If the Caret is at position [2], the default Run-command (Build in X-Code is used).
This is because #{...} is scoped as embedded Ruby source, which is explicitely filtered for the Run-Command. I didn't patch it, as I don't know which way to go (changing the scope or changing the scope selector for the command). But I hope the bundle maintainer can sort that out in a second :).
We are aware of this oddity, yes. We've discussed it in the past on IRC and the consensus was that the Ruby scopes involved need some reworking to help us clarify the filtered scopes. We've talked about how the scopes should be and will look at fixing this when we get those changes in place.
James Edward Gray II
On Nov 12, 2007 9:21 AM, James Edward Gray II james@grayproductions.net wrote:
On Nov 12, 2007, at 7:29 AM, Florian Gilcher wrote:
The following Ruby Script has a misbehaviour (please consider [1] and [2] as markers :):
puts "Here's 1 +[1] 1: #{ 1 +[2] 1}"
If the Caret is at position [1], Apple-R runs the program inside the ruby interpreter. If the Caret is at position [2], the default Run-command (Build in X-Code is used).
This is because #{...} is scoped as embedded Ruby source, which is explicitely filtered for the Run-Command. I didn't patch it, as I don't know which way to go (changing the scope or changing the scope selector for the command). But I hope the bundle maintainer can sort that out in a second :).
We are aware of this oddity, yes. We've discussed it in the past on IRC and the consensus was that the Ruby scopes involved need some reworking to help us clarify the filtered scopes. We've talked about how the scopes should be and will look at fixing this when we get those changes in place.
Hmmm. I wonder if this explains a strange occurence which I neglected to report.
I was editing an unsaved ruby program, and seemingly randomly cmd-R would bring up a save dialog box instead of running the program.
I've not done any XCode stuff, but I'm guessing that maybe the cmd-R for X-Code saves the code before running it?
On Nov 12, 2007, at 8:21 AM, James Edward Gray II wrote:
On Nov 12, 2007, at 7:29 AM, Florian Gilcher wrote:
The following Ruby Script has a misbehaviour (please consider [1] and [2] as markers :):
puts "Here's 1 +[1] 1: #{ 1 +[2] 1}"
If the Caret is at position [1], Apple-R runs the program inside the ruby interpreter. If the Caret is at position [2], the default Run-command (Build in X-Code is used).
This is because #{...} is scoped as embedded Ruby source, which is explicitely filtered for the Run-Command. I didn't patch it, as I don't know which way to go (changing the scope or changing the scope selector for the command). But I hope the bundle maintainer can sort that out in a second :).
We are aware of this oddity, yes. We've discussed it in the past on IRC and the consensus was that the Ruby scopes involved need some reworking to help us clarify the filtered scopes. We've talked about how the scopes should be and will look at fixing this when we get those changes in place.
As a temporary fix, we've relaxed the scope of this command. We'll worry about restricting it properly after the scopes are fixed up.
James Edward Gray II
-
Florian Gilcher -
James Edward Gray II -
Rick DeNatale