Auto-completion editor/IDE

[Eli Tucker]

Does anyone have any info on an IDE or editor that supports
auto-completion for Ruby?

So far I've been using Scite which came with the One-Click Windows Ruby
installer, but have not figured out how to turn on auto-completion (or
to be more specific, how to create the needed api file).

I just downloaded RDE, but the auto-completion seems half baked. For
example, if I type the following:

a = [4,2,3]
b = a.

a pop-up is shown just like you would expect where I can select a
method of Array. But then if I continue along to here:

a = [4,2,3]
b = a.sort
b.

.... no pop-up is shown -- it doesn't know that b is an Array.

Perhaps there isn't yet an IDE or editor for Ruby with auto-completion
features like those seen in Microsoft Visual Studio, Jet Brains IDEA,
or Eclipse? If not, I would be interested in hearing what other
developers are using to create ruby code.

Thanks in advance,
- Eli

 

[Tim Sutherland]

Does anyone have any info on an IDE or editor that supports
auto-completion for Ruby?

So far I've been using Scite which came with the One-Click Windows Ruby
installer, but have not figured out how to turn on auto-completion (or
to be more specific, how to create the needed api file).

I just downloaded RDE, but the auto-completion seems half baked. For
example, if I type the following:

a = [4,2,3]
b = a.

a pop-up is shown just like you would expect where I can select a
method of Array. But then if I continue along to here:

a = [4,2,3]
b = a.sort
b.

... no pop-up is shown -- it doesn't know that b is an Array.

Perhaps there isn't yet an IDE or editor for Ruby with auto-completion
features like those seen in Microsoft Visual Studio, Jet Brains IDEA,
or Eclipse? If not, I would be interested in hearing what other
developers are using to create ruby code.

I don't think there is one. It's a difficult problem because Ruby is such a
dynamic language (e.g. `method_missing'). (In fact, it's impossible to do a
perfect job automatically.)

I've been thinking a little about what would be needed to achieve at least
an "approximate" auto-completion.

Rdoc (inline documentation tool) gives us a list of classes and the methods they
implement. It allows for documenting methods/classes that it fails to find
automatically. I believe that any auto-completion system should use rdoc
data - if a method has been nicely documented you get auto-completion, and
otherwise you don't.

The missing component is the "type" a method returns. e.g. in your example,
that Array#sort returns an Array.

It's true that the methods an object responds to generally corresponds to
the instance methods of its class. So ignore the cases when this isn't true.

Also, methods can be redefined at runtime, e.g. Array#sort could be modified
to return a `MagicArray' having different methods. At least in these cases
the methods supported by the new return type should be approximately the
same as the old. (To preserve duck typing.) Ignore this problem.

Then add a tag to the rdoc markup for specifying return type(s) (as names of
classes). Methods defined in C extensions would need these to be specified
manually.

We can then do type inference on methods defined in Ruby to determine the
likely return types. We'll need some tricks for when many different types
can be returned, e.g. "def identity(x); x; end". Incorrect/incomplete
results can be fixed via the rdoc tag.

A big problem with this type guessing system is that when it gets a method
type wrong, the error will "bubble up" through the rest of the code, i.e.
any other method whose return value is from that method can be wrong too.
(Whereas if rdoc gets the methods of a class wrong, the error is localised.)

There are also some problems when the possible return "types" don't
correspond to any documented classes. e.g.
def method
class << Object.new
def hello
puts('hello'
end
end
end

Maybe we can live with these being wrong.


In a few weeks I may have time to experiment with these ideas. Whether
they're good probably depends whether confusion resulting from incorrect
inference causes more problems than it solves. (i.e. cure worse than the
complaint.)

 

[Tim Sutherland]

There are also some problems when the possible return "types" don't
correspond to any documented classes. e.g.
def method
class << Object.new
def hello
puts('hello'
end
end
end

Maybe we can live with these being wrong.

[...]

I meant:

def method
o = Object.new
class << o
def hello
puts('hello')
end
end
o
end

 

[Francis Hwang]

Patrick put it pretty well when we were hanging out talkin' Ruby night:
He said "The same features that make Ruby fun for humans to write makes
it hard for computers to read." All the extra typing you do for, say,
Java, makes it a lot easier to write things like auto-completion,
refactoring tools, etc.

At any rate, one thing I'd look at is 'irb/completion', which does
auto-completion in irb. I haven't looked at the internals, but I use it
all the time and it would be probably be a good place to start.

F.

Eli Tucker
wrote:

Does anyone have any info on an IDE or editor that supports
auto-completion for Ruby?

So far I've been using Scite which came with the One-Click Windows
Ruby
installer, but have not figured out how to turn on auto-completion (or
to be more specific, how to create the needed api file).

I just downloaded RDE, but the auto-completion seems half baked. For
example, if I type the following:

a = [4,2,3]
b = a.

a pop-up is shown just like you would expect where I can select a
method of Array. But then if I continue along to here:

a = [4,2,3]
b = a.sort
b.

... no pop-up is shown -- it doesn't know that b is an Array.

Perhaps there isn't yet an IDE or editor for Ruby with auto-completion
features like those seen in Microsoft Visual Studio, Jet Brains IDEA,
or Eclipse? If not, I would be interested in hearing what other
developers are using to create ruby code.

I don't think there is one. It's a difficult problem because Ruby is
such a
dynamic language (e.g. `method_missing'). (In fact, it's impossible to
do a
perfect job automatically.)

I've been thinking a little about what would be needed to achieve at
least
an "approximate" auto-completion.

Rdoc (inline documentation tool) gives us a list of classes and the
methods they
implement. It allows for documenting methods/classes that it fails to
find
automatically. I believe that any auto-completion system should use
rdoc
data - if a method has been nicely documented you get auto-completion,
and
otherwise you don't.

The missing component is the "type" a method returns. e.g. in your
example,
that Array#sort returns an Array.

It's true that the methods an object responds to generally corresponds
to
the instance methods of its class. So ignore the cases when this isn't
true.

Also, methods can be redefined at runtime, e.g. Array#sort could be
modified
to return a `MagicArray' having different methods. At least in these
cases
the methods supported by the new return type should be approximately
the
same as the old. (To preserve duck typing.) Ignore this problem.

Then add a tag to the rdoc markup for specifying return type(s) (as
names of
classes). Methods defined in C extensions would need these to be
specified
manually.

We can then do type inference on methods defined in Ruby to determine
the
likely return types. We'll need some tricks for when many different
types
can be returned, e.g. "def identity(x); x; end". Incorrect/incomplete
results can be fixed via the rdoc tag.

A big problem with this type guessing system is that when it gets a
method
type wrong, the error will "bubble up" through the rest of the code,
i.e.
any other method whose return value is from that method can be wrong
too.
(Whereas if rdoc gets the methods of a class wrong, the error is
localised.)

There are also some problems when the possible return "types" don't
correspond to any documented classes. e.g.
def method
class << Object.new
def hello
puts('hello'
end
end
end

Maybe we can live with these being wrong.


In a few weeks I may have time to experiment with these ideas. Whether
they're good probably depends whether confusion resulting from
incorrect
inference causes more problems than it solves. (i.e. cure worse than
the
complaint.)

 

[Tim Sutherland]

Patrick put it pretty well when we were hanging out talkin' Ruby night:
He said "The same features that make Ruby fun for humans to write makes
it hard for computers to read." All the extra typing you do for, say,
Java, makes it a lot easier to write things like auto-completion,
refactoring tools, etc.

Very true.

At any rate, one thing I'd look at is 'irb/completion', which does
auto-completion in irb. I haven't looked at the internals, but I use it
all the time and it would be probably be a good place to start.

irb/completion basically just uses `foo.methods'. irb is doing completion at
runtime. In an editor you really want compile-time completion.

 

[gabriele renzi]

Tim Sutherland ha scritto:

irb/completion basically just uses `foo.methods'. irb is doing completion at
runtime. In an editor you really want compile-time completion.

you don't necessarily need to have the two separated, just think of the
smalltalk environments.
A friend of mine points out often how cool the SLIME system for lisp
(based on emacs) is, and it is basically an ide talking to a live
environment (think of bridging irb and freeride or whatever)

 

[Eivind Eklund]

Perhaps there isn't yet an IDE or editor for Ruby with auto-completion
features like those seen in Microsoft Visual Studio, Jet Brains IDEA,
or Eclipse?

Tim Sutherland had a nice description of the problems in this, and the
approaches necessary to make it more or less work (and I think it
could work quite nicely for most day to day work, but there will be
breakdowns).

If not, I would be interested in hearing what other developers are using to
create ruby code.

I use vim, including use of its text based completion (Ctrl-N). This
completes the rest of the word/identifier I'm typing, and saves me
from getting typos in long identifiers (plus the typing, but that's
IMO less important.)

Eivind.

 

[Alexey Verkhovsky]

Tim Sutherland ha scritto:

Some people were writing about continuous unit testing (where a test
runner senses file changes, runs test suite automatically and reports
problems, if any.

Maybe the way to make Ruby development environment more aware about the
code is somewhere along these lines?

Alex

 

[Eli Tucker]

Thanks for the thoughtful replies.

Eivind, I'm curious how vim knows what to complete with. Where does it
get the data?

Tim, thanks for rundown of the issues. I must admit that I didn't think
the impact of the dynamic nature of Ruby causing these problems.

Gabriele, I actually thought of this. Could there be some way in which
the IDE could be executing the program in memory, but not really
executing it -- just enough so that it can call whatever.methods? I'm
too new to the Ruby world to know if this type of things is possible.
- Eli

 

[Bill Atkins]

If it's anything like Emacs, it probably just looks for matching
symbols in the rest of the file. I could be wrong, though.

Bill

 

[Eivind Eklund]

Thanks for the thoughtful replies.

Eivind, I'm curious how vim knows what to complete with. Where does it
get the data?

vim looks in the loaded buffers, with priority rules that usually gets
things right (at least for me - but I'm used to them).

It isn't perfect but it is very useful.

Eivind.

 

[Tim Sutherland]

I wrote a jEdit macro and ruby script that performs naïve code
completion using ri. Currently it runs incredibly slow, but as a proof
of concept it was a success.

My naïve approach is to assume that if it quacks like a duck, it
probably waddles like a duck too. Unfortunately if we haven't heard
any quacks yet, then it's difficult to assume waddling or anything
else.

The jEdit beanshell macro executes a Ruby script that does the following:
1) determines methods that have already been called on the variable
2) uses a slightly modified version of ri to find classes that have
all those methods
3) uses ri again to find all the methods available on those classes

The jEdit macro then displays a popup list of the methods for the user
to select from. In the case of a variable being declared like this:
variable = Duck.new
we know we have a duck so the script can immediately jump to step 3.

[...]

Nice! This is a clever idea. How well does it work?

 

[Hernan Silberman]

Hello,

I'm in the early stages of learning Ruby. I've been playing with std
library classes to get situated a bit and I can't get this simple
GServer subclass to run properly. It's taken straight from the
GServer class docs. I'm running ruby 1.8.1 on cygwin/winXP.

require 'gserver'
class SimpleServer < GServer
def initialize(port=10001,*args)
super(port,*args)
end
def serve(io)
io.puts(Time.now.to_i)
end
end

theS = SimpleServer.new
theS.audit = true
theS.start

When I run it, I get this:

$ ruby NetTest.rb
[Fri Oct 29 22:10:28 2004] SimpleServer 127.0.0.1:10001 start
[Fri Oct 29 22:10:28 2004] SimpleServer 127.0.0.1:10001 stop

No error, but I'm assuming there was some problem binding to port
10001 or otherwise starting the server. How can I dig a little deeper
to find the cause of the problem?

many thanks...
Hernan

 

[Brian Mitchell]

Hello,

I'm in the early stages of learning Ruby. I've been playing with std
library classes to get situated a bit and I can't get this simple
GServer subclass to run properly. It's taken straight from the
GServer class docs. I'm running ruby 1.8.1 on cygwin/winXP.

require 'gserver'
class SimpleServer < GServer
def initialize(port=10001,*args)
super(port,*args)
end
def serve(io)
io.puts(Time.now.to_i)
end
end

theS = SimpleServer.new
theS.audit = true
theS.start

When I run it, I get this:

$ ruby NetTest.rb
[Fri Oct 29 22:10:28 2004] SimpleServer 127.0.0.1:10001 start
[Fri Oct 29 22:10:28 2004] SimpleServer 127.0.0.1:10001 stop

No error, but I'm assuming there was some problem binding to port
10001 or otherwise starting the server. How can I dig a little deeper
to find the cause of the problem?

many thanks...
Hernan

You may want to join to the server thread. Try adding:

theS.join

to the last part of your code snippet. What is happening is the server
object is being garbage collected because your program is exiting.

Peace,
Brian Mitchell.