Ruby and IDE
the_mindstorm
I expect that this topic to have been discussed way to many times on the ml, so I would like to
excuse me for re-opening it.
I am doing Java development for quite a while (since 98) and lately with all the news around Ruby I
have started lookin' in. I see a lot of movement around, many great ideas and a lot of efforts going
in.
But, there is one 'little' aspect that bugs me. Imo, the tools around a language will take it from a
'niche' and transform it to an 'big success'. While I see a lot of nice ideas put into different
type framework, I cannot see any big effort going to an IDE.
I am seeing some of them around:
- Ruby support in vim
- Ruby support in Emacs
- Mondrian Ruby IDE
- FreeRIDE
- Arachno Ruby (I feel this is the only one going to the right direction ;-)),
but none of them are at a level comparable with real IDEs (being them IDEs for Java, Python,
C/C++/C#, etc). I am wondering why aren't the Ruby community considering this an important aspect?
[intermezzo]
A few months ago Cedric Beust (http://beust.com) and myself (http://themindstorms.blogspot.com) have
launched a new unit-integration testing framework. We had good reviews right from the start, but
after launching an Eclipse plugin, the feedback was just 'great'.
[/intermezzo]
I have run through different Ruby books and currently I wanted to start looking more deeply. As my
time doesn't allow me too much research, I 'gems' installed a few simple distros just to look at 'em
and see Ruby at work. But working with vim (and I did a lot of Java dev, back in time) seems to me
deprecate (sorry, I don't want to start a flame - it is just an opinion). I have never been able to
use Emacs decently (this is probably only my fault), FreeRIDE is not there for me and only Arachno
seems promising to me (not an affiliate of Arachno ;-) - unfortunately commercial product and I
don't thing any guy starting with Ruby will jump to buy it, even if this would be great for Mr.
Lothar Scholz).
What I would like to see:
1/ project management
2/ integrated documentation (API documentation)
3/ easy source code navigation (like go to declaration, implement this method, etc)
4/ autocompletion
5/ probably many others I don't remember now.
I would like to find out your opinion on this matter, from the point of more experienced Ruby
developers.
tia,
--:alex |.::the_mindstorm::.|
Johan Toki Persson
enough. :-)
No seriously, I dont't have the slightest. I guess the average rubyist
are quite satisfied with either vim or emacs.
Lothar Scholz
t> but none of them are at a level comparable with real IDEs
t> (being them IDEs for Java, Python,
t> C/C++/C#, etc). I am wondering why aren't the Ruby community
t> considering this an important aspect?
No they do not. I'm really surprised how hostile some ruby developers
are against IDE's and tool support. Especially some of the well known
oldtimers here in the group. Even when you point them to the benefits
in other IDE's, for example in the smalltalk area you get disgusting
comments. Until now the community is still very dominated by
technical geeks which is not a good thing.
One of the problems with writting an IDE is that it takes an enourmous
amount of time. You must expect 5 years minimum and Ruby is a new
language, at least in the western part of this world.
t> [intermezzo]
t> A few months ago Cedric Beust (http://beust.com) and myself
t> (http://themindstorms.blogspot.com) have
t> launched a new unit-integration testing framework. We had good
t> reviews right from the start, but
t> after launching an Eclipse plugin, the feedback was just 'great'.
t> [/intermezzo]
Same here.
t> use Emacs decently (this is probably only my fault), FreeRIDE
t> is not there for me and only Arachno
t> seems promising to me (not an affiliate of Arachno ;-) -
t> unfortunately commercial product and I
t> don't thing any guy starting with Ruby will jump to buy it,
Right i don't expect this either. Even when i see that the price is
not higher then a usual game and ruby is much more fun in the long
run.
t> 1/ project management
Is done in Aracho.
t> 2/ integrated documentation (API documentation)
Difficult with the current state of Ruby. We still lack a good
documentation standard. RDoc is one step but it misses so much
and is unclear in many others. The huge problem is that there is no
official API to the internal database, even the Seven-Click Installer
installs it wrong - the answer i got aobut this was:
Yes you are right, but it works. Yes it works but it is not good
if you want to build tools and other infrastructure on top of it.
This shows the whole state of the community at the moment and the
resulting problems.
t> 3/ easy source code navigation (like go to declaration, implement this method, etc)
Time consuming, just because you must build a complete repository of
all accessible items. This must be robust and fast to search and the
whole concept does not work well with normal file level editors like
vi and emacs.
t> 4/ autocompletion
Difficult in a dynamic language like ruby. We discussed this to death
in the past. Please use google.
t> 5/ probably many others I don't remember now.
Many many others. And everybody has its own preference, some only want
a debugger but there they want the best one, for others a profiler would
be the most important and there are people who would not accept anything
if it does not look like a Smalltalk image.
And many people are asking about support for rails, they don't have
concrete ideas, they just want to see something for rails. Not easy
for someone like me.
--
Best regards, emailto: scholz at scriptolutions dot com
Lothar Scholz http://www.ruby-ide.com
CTO Scriptolutions Ruby, PHP, Python IDE 's
Richard Dale
> But, there is one 'little' aspect that bugs me. Imo, the tools around a
> language will take it from a 'niche' and transform it to an 'big success'.
> While I see a lot of nice ideas put into different type framework, I
> cannot see any big effort going to an IDE. I am seeing some of them
> around: - Ruby support in vim
> - Ruby support in Emacs
> - Mondrian Ruby IDE
> - FreeRIDE
> - Arachno Ruby (I feel this is the only one going to the right direction
> ;-)),
Have a look at Eclipse with the ruby plugin, or KDevelop 3.2 as well.
Perhaps there should be a ruby IDE/dev tools FAQ.
Alex the_mindstorm Popescu
My current project (Java) size: aprox.2000 classes. I don't think this is nice manageable in a vim
environment (and remember I've been there ;-)).
I have seen this "vim or emacs is enough behavior", and I interpret it much like a: "hey if you are
not an elite to use vim/emacs, you have not the right to use xxx" (programming language for elites),
and this is _completely_ wrong. Imo this support is mandatory (I can give you lots of examples about
nice technologies/ideas that remained little - maybe even are dead now - because of the lack of tool
support).
I really believe (and I am sure almost all of you accept this ;-) ) that an IDE is helping a lot the
development of real world projects and it brings a lot of efficiency to experienced developers, but
is also helping beginners to become proficient.
Again, I will ask you to forgive my vehement position and I want to underline that I am not writing
this to start flames.
[Answer to Lothar:]
I am really enjoying Arachno and I intent to buy a license soon (even if .... - this will be a
personal mail ;-).
I am not saying that those features are easy/hard to support, as I am not an expert in programming
languages and also not an IDE guru developer. All I know is that even if the effort is big, the
reward will be bigger. I haven't mentioned features that are not available for example in Smalltalk.
Afaik Ruby is around since 2000, so the 5 years are gone ;-).
[Answer to Richard:]
- tried that too. Unfortunately, its offerings are the same as in other specified tools.
Steve Callaway
1600 Java classes) finally resolved down to about 3
embedded C objects (for things like CRC checking which
weren't readily available in Ruby at the time - going
to put my CRC stuff up on RubyForge sometime btw once
I have removed all my idiosyncratic and/or proprietary
stuff from it) and a handful of Ruby support classes
and modules(maybe 15 or so) when I finally summoned up
the courage to get rid of the Java bloat. Maintenance,
once a nightmare, is frankly a trivial matter now. The
problem with Java is you just can't see the wood from
the trees, which is //not// the case with Ruby.
--- Alex the_mindstorm Popescu
Richard Dale
> [Answer to Richard:]
> - tried that too. Unfortunately, its offerings are the same as in other
> specified tools.
I'm not sure what you mean here, which features in KDevelop were lacking?
Code completion isn't easy to do in ruby, but apart from that it has most
things on your list. I haven't used Eclipse, but I'd be interested in a
review of that for ruby development, such as how the debugger compares with
the other IDEs and so on.
Alex the_mindstorm Popescu
>-----Original Message-----
>From: Steve Callaway [mailto:sjc20...@yahoo.com]
>Sent: Thursday, April 28, 2005 11:45 AM
>To: ruby-talk ML
>Subject: Re: Ruby and IDE
>
>now. The problem with Java is you just can't see the wood from
>the trees, which is //not// the case with Ruby.
>
I will take this as a joke for the moment ;-). Even at a scale of 1:20 lines, managing 20k lines of
code is not so easy. And refusing to address the problem because we find different workarounds is
not a solution (my 2c).
The feeling is that for my playground I will probably be able to use one of the enumerated
environment. But I surely can guarantee that convincing a company to go for development with Ruby
will be 'daaaaaaaaaaaaaaaaaaamn' hard.
cheers,
--:alex |.::the_mindstorm::.|
>--- Alex the_mindstorm Popescu
Rob .
release of the Ruby Editor Plugin for jEdit, hopefully out in the next
week. A documentation window will show next to the method list popup,
so this will be a great tool for those new to Ruby. Alex, Ruby Editor
Plugin pentru jEdit e cel mai bun*!
http://www.jedit.org/ruby/
What's missing from the Ruby IDE space is an editor let's you
manipulate Ruby at the syntax level. For Java, modern IDEs let me
think in terms like "method complete", "find declaration", "find
usages", "extract variable", "rename member", "extract method",
"change method signature", "go to last edit", "go to last location",
etc. jEdit's Ruby Editor Plugin is evolving into this style of IDE.
Not having to think about the more low-level textual manipulations
frees your mind to make syntactical ones; obviously important in a
verbose language like Java, but also of value to large-scale Ruby
development projects.
Cheers,
Rob
*Am lucrat pentru optspre luni in Timisoara. Stiu un pic Romaneste.
Thomas Kirchner
> No they do not. I'm really surprised how hostile some ruby developers
> are against IDE's and tool support. Especially some of the well known
> oldtimers here in the group. Even when you point them to the benefits
> in other IDE's, for example in the smalltalk area you get disgusting
> comments. Until now the community is still very dominated by
> technical geeks which is not a good thing.
Just to chime in my opinion... I'm not "hostile" to IDEs, I've given them
a shot. The biggest sticking point for me is a good IDE would need to
have a vim text-editing part. Customizable key bindings or vi-like
behavior wouldn't be enough, it would need vim embedded. Until this is
accomplished, an environment just could not be productive for me - as
said in another thread, it's a life changing editor ;)
> t> 3/ easy source code navigation (like go to declaration, implement
> this method, etc)
> Time consuming, just because you must build a complete repository of
> all accessible items. This must be robust and fast to search and the
> whole concept does not work well with normal file level editors like
> vi and emacs.
Integrated documentation would be nice, but this would be even better
(after all, I've got my handy-dandy pickaxe, which is hard to beat). A
well-integrated resource for navigating full projects would be great, as
the solutions for vim aren't quite up to the level required, as far as
I've seen.
> t> 4/ autocompletion
> Difficult in a dynamic language like ruby. We discussed this to death
> in the past. Please use google.
Obviously, this is incredibly difficult for ruby. However, when I've
used IDEs in the past, this was exactly what I appreciated most. I think
it'd be possible to get some basic autocompletion, skipping some of the
more difficult dynamic elements, and most people would be happy, if not
content.
> t> 5/ probably many others I don't remember now.
> Many many others. And everybody has its own preference, some only want
> a debugger but there they want the best one, for others a profiler would
> be the most important and there are people who would not accept anything
> if it does not look like a Smalltalk image.
I think the most important feature(s) for me, and many others when they
think about it, is stability and speed. You should not be hampered by
your environment, whether through delays or crashes/bugs. When I tried
FreeRIDE a little while ago, it unfortunately couldn't pass this test.
The devs have made great progress, but it was still a bit slow and
unstable. (I should really give it another try now though, as they've
made new minor releases.)
Tom
John Wells
> What's missing from the Ruby IDE space is an editor let's you
> manipulate Ruby at the syntax level. For Java, modern IDEs let me
> think in terms like "method complete", "find declaration", "find
> usages", "extract variable", "rename member", "extract method",
> "change method signature", "go to last edit", "go to last location",
> etc. jEdit's Ruby Editor Plugin is evolving into this style of IDE.
AMEN! Everything you've mentioned above makes Eclipse such a powerful
boon to our Java development. For example, I can highlight any method or
field and hit F3 and instantly be taken to where that entity was declared,
in *any* included file. This is POWER.
Regarding Lothar's comment about this being time consuming...it's time
well spent. I've seen other IDEs for other languages handle this by
building a database of all includes on first run or on project creation,
and then giving the user the ability of rebuilding this database at will.
I'm happy to waste some time building and rebuilding this type of database
to gain these features. Please consider supporting the features Rob
mentions in ArachnoRuby...I've been very pleased with my evaluation so far
but the lack of these is a show stopper when considering an IDE purchase,
if that IDE doesn't endeavor to support them.
In reply to Rob, I'm curious why you've opted to go the jEdit route and to
not get involved with the RubyEclipse plugin. I'm a long time jEdit user
(have contributed a plugin as well:
http://sourceillustrated.com/jasperjedit), but Eclipse IMHO has many of
the necessary scaffolding for the features you mentioned before already
there, while jEdit can be more of a pain to assemble just the right
plugins, etc. I personally would love to see more of a community effort
in regards to Ruby for Eclipse. jEdit is nice as an editor with IDE-like
features, but Eclipse is truly an IDE in every sense of the word.
Just my two cents.
Thanks,
John
Joost Diepenmaat
> * On Apr 28 17:45, Lothar Scholz (ruby...@ruby-lang.org) wrote:
> > No they do not. I'm really surprised how hostile some ruby developers
> > are against IDE's and tool support.
My main problem with IDE's is that they take up too much resources
(screen, memory and time) - and I haven't seen one that offers
significant benefits for dynamic languages. I occasionally use eclipse
for java refactoring jobs (moving classes, conversion of method
signatures etc), but:
1. you can't do perfect static analysis on a dynamic languge, so providing
all the cool stuff that eclipse provides for java is much more difficult
or impossible to do correctly for ruby.
2. there is far less boiler-plate code in ruby and perl, so I don't
need it as much.
> > Until now the community is still very dominated by
> > technical geeks which is not a good thing.
Since I am a technical geek, even though I'm new to Ruby, I don't mind
this at all :-)
> Just to chime in my opinion... I'm not "hostile" to IDEs, I've given them
> a shot. The biggest sticking point for me is a good IDE would need to
> have a vim text-editing part. Customizable key bindings or vi-like
> behavior wouldn't be enough, it would need vim embedded. Until this is
> accomplished, an environment just could not be productive for me - as
> said in another thread, it's a life changing editor ;)
Plugging in vim would help, yeah.
> > t> 4/ autocompletion
> > Difficult in a dynamic language like ruby. We discussed this to death
> > in the past. Please use google.
>
> Obviously, this is incredibly difficult for ruby. However, when I've
> used IDEs in the past, this was exactly what I appreciated most. I think
> it'd be possible to get some basic autocompletion, skipping some of the
> more difficult dynamic elements, and most people would be happy, if not
> content.
To do this correctly (for some values of correct), you'd probably have to
introspect the running code. I gather that some SmallTalks do this -
I've never used smalltalk but it appears to me that this is very different
way of programming than I'm used to - like building programs in an
interactive shell.
> > t> 5/ probably many others I don't remember now.
> > Many many others. And everybody has its own preference, some only want
> > a debugger but there they want the best one, for others a profiler would
> > be the most important and there are people who would not accept anything
> > if it does not look like a Smalltalk image.
>
> I think the most important feature(s) for me, and many others when they
> think about it, is stability and speed.
Yup. Any editor that can't keep up with my typing speed / menu selection is
too slow. Anything that isn't rock-stable isn't worth using.
Joost.
Austin Ziegler
>> Johan Toki Persson [mailto:tokik...@gmail.com ]:
>> We're not a craving bunch. Hacking in such a wonderful language
>> is good enough. :-) No seriously, I dont't have the slightest. I
>> guess the average rubyist are quite satisfied with either vim or
>> emacs.
> My current project (Java) size: aprox.2000 classes. I don't think
> this is nice manageable in a vim environment (and remember I've
> been there ;-)).
I'm working on a relatively large project in Ruby -- PDF::Writer.
This is not a small project in Ruby; it has between 40 and 60
classes and represents about six months continuous work. It also
uses a few other classes that I've refactored out.
ActionMailer (part of Rails) is similar -- it looks to be about 40
classes. (There's a lot of files that are 10k or less in
ActionMailer.)
I think that part of the reason that a lot of people are happy --
satisfied, even -- with vim and emacs for Ruby (and Rails)
development is that there's a lot *less* code.
How many of your 2000 classes are *useful* classes that do real
work? How many of your 2000 classes are necessary because of the
nightmare that is Java enterprise application programming? (When I
looked at "Code Generation in Action", I was amazed at how many
classes had to be generated for a single table/view combination.)
If, as I suspect, there's a 1:4 useful:framework ratio, then you're
talking about 400 classes that do real work. In PDF::Writer,
although I've got 40 - 60 classes (in about 35 files), I am working
mostly in -- get this -- three files. How many files do you work in
mostly? If your percentages are similar, then you're probably
working with about 35 files.
In a C++ project that I am doing at work, there's a similar ratio.
At any given time, I'm working with between three and fifteen files.
I will use the VisualStudio environment for code completion and a
few project-centric searches (it's a bit smarter than a text search
that I do on Windows, but equally smart to a good find-grep search
that I do on our Unix ports), and for integrated debugging, but
that's about it. I do 95% of my code editing in vim.
Interesting SLOCCount stats for PDF::Writer:
Total SLOC : 5,980
Person-Years Estimate (COCOMO) : 1.31 (15.69 months)
Schedule Estimate (COCOMO) : 0.59 (7.12 months)
Estimated Developers: : 2.21
Estimated Cost: : $ 176,676
> I have seen this "vim or emacs is enough behavior", and I
> interpret it much like a: "hey if you are not an elite to use
> vim/emacs, you have not the right to use xxx" (programming
> language for elites), and this is _completely_ wrong. Imo this
> support is mandatory (I can give you lots of examples about nice
> technologies/ideas that remained little - maybe even are dead now
> - because of the lack of tool support).
Then you are interpreting this incorrectly, at least for Ruby. You
can use any editor to work with Ruby. There is some support for Ruby
in the major cross-language IDEs, but Ruby is a notoriously
difficult language to provide full IDE capabilities for.
> I really believe (and I am sure almost all of you accept this ;-)
> ) that an IDE is helping a lot the development of real world
> projects and it brings a lot of efficiency to experienced
> developers, but is also helping beginners to become proficient.
Mmmm. I don't necessarily agree. An IDE can help, certainly, with
things that are difficult to remember often. An IDE can also provide
an environment for bad code. In the Java world, an IDE is almost
certainly necessary to deal with the idiocies behind the library
design. In the MS world, an IDE is almost certainly necessary to
deal with the massive API set (and some of the idiocies behind the
library design).
In Ruby, I think that an IDE is much less necessary and useful. Code
completion is very unlikely to be possible on a Ruby IDE, at least
inasmuch as developers have come to expect with IDEs for statically
typed languages.
Can you point me to a Python IDE or three? I'd like to look at them
to see if they come close to what VisualStudio can do, even, for
C++.
-austin
--
Austin Ziegler * halos...@gmail.com
* Alternate: aus...@halostatue.ca
Rob .
> In reply to Rob, I'm curious why you've opted to go the jEdit route and to
> not get involved with the RubyEclipse plugin.
I choose to write Ruby support for jEdit because:
1) It seemed the quickest way for me to implement the features I
wanted. I was familiar with jEdit from prior work on the XSLT and
XMLIndenter plugins.
2) The eclipse interface hasn't appealed to me. I prefer the
simplicity of the side-dockable windows in IntelliJ IDEA and jEdit, to
Eclipse's constraining view/perspective approach. I use IDEA for Java
development and jEdit for everything else.
3) Politically I find jEdit's GPL licensing terms more palatable to
Eclipse's and RubyEclipse's CPL licensing. If I contribute many hours
of my personal time to writing an free software Ruby editor based
heavily on others free software efforts, I don't want to license that
work under terms that allow a corporation to take it and release it
commercially.
Note that the GPL and CPL licenses are incompatible. So I can't just
take code from the RubyEclipse project and neither can they take my
code, unless we reach a separate licensing agreement.
4) I tend to back the underdog, often because it's the best. (Perhaps
that's why I was attracted to Ruby not Python or Perl, REST not SOAP,
and Topic Maps not RDF).
Slava started writing jEdit when he was 15 years old. I prefer to back
projects started by people solving problems, not projects started by
corporations for profit (assuming IBM started Eclipse with a
profit-motive in mind). Vendors and consortium's often produce
bloated, overly complex specifications and software, in order to
extract oligopoly profits from markets through consulting/support
revenues and by putting up technical and legal barriers to entry.
I don't expect anyone to agree with me. Hopefully if I write something
good, you'll use it. Maybe someone will even be able to help me by
writing a debugger. ;-)
Cheers,
Rob
http://www.jedit.org/ruby/
Paul Hanchett
> Code completion isn't easy to do in ruby, but apart from that it has most
> things on your list. I haven't used Eclipse, but I'd be interested in a
> review of that for ruby development, such as how the debugger compares with
> the other IDEs and so on.
Isn't the thing that makes code completion difficult the fact that most
Ruby tools don't have a proper notion of a "Project"? PHP has a similar
issue, but in Eclipse I can define a PHP project. It scans the source
and presto completion works and so does a lot of other great stuff!
I haven't done much Ruby coding yet, so I can't say whether the Ruby
support for Eclipse does the same.
(BTW, when I say "It's easy" I'm not claiming that I could do it. OK?
;-) )
Christian Neukirchen
> On 4/28/05, Alex the_mindstorm Popescu <the_mi...@evolva.ro> wrote:
>> My current project (Java) size: aprox.2000 classes. I don't think
>> this is nice manageable in a vim environment (and remember I've
>> been there ;-)).
>
> If, as I suspect, there's a 1:4 useful:framework ratio, then you're
> talking about 400 classes that do real work. In PDF::Writer,
> although I've got 40 - 60 classes (in about 35 files), I am working
> mostly in -- get this -- three files. How many files do you work in
> mostly? If your percentages are similar, then you're probably
> working with about 35 files.
Well, you obviously forgot that Java forces you to use one file per
class (or did they change that stupid requirement recently?).
I couldn't deal with 2000 files in Emacs either, but 35 files and the
same LOC would be no problem (esp. as you focus on a handful at once
only). :-)
> -austin
--
Christian Neukirchen <chneuk...@gmail.com> http://chneukirchen.org
Joe Van Dyk
> Rob . said:
> > What's missing from the Ruby IDE space is an editor let's you
> > manipulate Ruby at the syntax level. For Java, modern IDEs let me
> > think in terms like "method complete", "find declaration", "find
> > usages", "extract variable", "rename member", "extract method",
> > "change method signature", "go to last edit", "go to last location",
> > etc. jEdit's Ruby Editor Plugin is evolving into this style of IDE.
>
> AMEN! Everything you've mentioned above makes Eclipse such a powerful
> boon to our Java development. For example, I can highlight any method or
> field and hit F3 and instantly be taken to where that entity was declared,
> in *any* included file. This is POWER.
In vim, I put the cursor over the method, hit ctrl-] and i'm taken to
where the method was defined. Thanks to my handy-dandy tags file!
Richard Dale
> Richard Dale wrote:
>
>> Code completion isn't easy to do in ruby, but apart from that it has most
>> things on your list. I haven't used Eclipse, but I'd be interested in a
>> review of that for ruby development, such as how the debugger compares
>> with the other IDEs and so on.
>
> Isn't the thing that makes code completion difficult the fact that most
> Ruby tools don't have a proper notion of a "Project"? PHP has a similar
> issue, but in Eclipse I can define a PHP project. It scans the source
> and presto completion works and so does a lot of other great stuff!
No, the problem is that often you can't tell the type of a ruby variable
until runtime (but can you do that for PHP either?). And we do discuss how
to attempt to solve the problem quite regularly on this list. For instance,
if I assign '@a = FooBar.new' and @a only gets assigned to in one place,
then maybe I can assume variable '@a' is a FooBar, but other times it isn't
so clear. I use that kind of hueristic for showing the type of a variable
in the KDevelop class browser, but it's by no means water tight. Unless
code completion is 100% reliable, it might well be more annoying than no
code completion at all.
KDevelop has the notion of a project, and it has code completion for C++ and
other languages - so all the infrastructure is there. But, but..
> I haven't done much Ruby coding yet, so I can't say whether the Ruby
> support for Eclipse does the same.
I don't think the Eclipse plugin does code completion, but it's nice to get
feedback on what the various tools do best and how they compare with each
other.
> (BTW, when I say "It's easy" I'm not claiming that I could do it. OK?
> ;-) )
No problem, although actually I think you were wondering why we found it so
difficult..
Ben Giddings
> I have never been able to
> use Emacs decently (this is probably only my fault), FreeRIDE is not
See, that's the problem. When you *can* use Emacs or vi decently, the need
for an IDE doesn't really seem to be there.
Here's the deal. When you're writing software in language Foo you want:
* An editor that is very good at editing text
* An editor that understands Foo
* An environment that allows you to do all the other tasks (debug, run,
integrate, copy files, check files into source control, ...)
If you're writing software in languages Foo, Bar, Baz and Smeg, you want:
* An editor that is very good at editing text
* An editor that understands Foo, Bar, Baz and Smeg
* An environment that allows you to do all the other tasks (debug, run,
integrate, copy files, check files into source control, ...)
* Ideally only one editor, so you don't have to context-switch all the
time, remembering that Ctrl-X is "exit" in one and "prefix-X" in the other
Emacs and vi are astounding at editing text. I doubt there's anything out
there that can do more. They also happen to have some pretty good support
for a whole lot of different languages.
Emacs is also very good at letting you do other tasks. I don't think
people use vi this way, they just use the commandline, but the commandline
is also very good at letting you do other tasks.
What does a typical IDE give you? It gives you an editor that isn't quite
as good as Emacs or vi at editing text. It gives you an environment that
is extremely good at managing a small subset of other tasks, but only the
ones the IDE designers anticipated, and it gives you extremely good
support for a small subset of languages.
If you take the time to learn Emacs and vi, you won't always have an editor
that is amazing at Foo, but you'll always have an excellent text editor,
and often one that is pretty good at Foo.
If there were an editor that was better than Emacs at editing Ruby code,
and as good as Emacs at everything else I use Emacs for... then I'd
switch. But switching to an editor that is slightly better for Ruby, but
not nearly as good at everything else just doesn't make sense to me.
Ben
Lothar Scholz
RD> No, the problem is that often you can't tell the type of a ruby variable
RD> until runtime (but can you do that for PHP either?). And we do discuss how
Almost all PHP projects i know are functional. So you don't have a
problem with code completition - just show all variables and functions
or simply the ones with the given prefix. In the few cases where there
is a $self-> reference they run into the same problems, but PHP code
is much easier structured so your mentioned heuristic and a few more
work very well.
Does the KDevelop class browser really show all available methods ?
Rubys scoping rules with includes of modules (global, local) are
very complex, is this really handled ? If so - then even as a
competitor - i must show deep respect.
If not then it is much easier, but remember that most people want to use code
insight/autocomplete as a reference and a help to learn the API.
Then it is maybe more confusing to show something incomplete and
errornous. I observe my competitors very well (here i mostly mean Wing-IDE for
Python) and even while there system is very sophisticated i hear a lot
of comments that it is confusing.
Thats why my in current plans it had a lower priority. But i come to the
conclusion that this is far more wanted then i expected. So i will implement
my interpretation of a good code insight system very soon.
I have now changed my schedule in a way that in 3 3 month i hope i
can come up with something but as i wrote before it will look and
behave a little bit different...
Richard Dale
> Hello Richard,
>
> RD> No, the problem is that often you can't tell the type of a ruby
> variable RD> until runtime (but can you do that for PHP either?). And we
> do discuss how
>
> Almost all PHP projects i know are functional. So you don't have a
> problem with code completition - just show all variables and functions
> or simply the ones with the given prefix. In the few cases where there
> is a $self-> reference they run into the same problems, but PHP code
> is much easier structured so your mentioned heuristic and a few more
> work very well.
>
> Does the KDevelop class browser really show all available methods ?
> Rubys scoping rules with includes of modules (global, local) are
> very complex, is this really handled ?
No, the KDevelop class browser isn't very clever at all, just some regular
expression matching. I'd like the next version to use the ruby bison
grammar and tokeniser.
> If so - then even as a
> competitor - i must show deep respect.
I don't see you as a competitor, as I've been mainly working on the QtRuby
and Korundum bindings, and have spent only a couple of months or so on
KDevelop ruby support. If Arachno was a killer development environment for
those apis I would be very pleased. For instance, I mailed you the other
month about the debugger conventions that QtRuby uses, in case you wanted
to make some minor changes to the Arachno debugger to handle QtRuby.
> If not then it is much easier, but remember that most people want to use
> code insight/autocomplete as a reference and a help to learn the API.
> Then it is maybe more confusing to show something incomplete and
> errornous. I observe my competitors very well (here i mostly mean Wing-IDE
> for Python) and even while there system is very sophisticated i hear a lot
> of comments that it is confusing.
>
> Thats why my in current plans it had a lower priority. But i come to the
> conclusion that this is far more wanted then i expected. So i will
> implement my interpretation of a good code insight system very soon.
> I have now changed my schedule in a way that in 3 3 month i hope i
> can come up with something but as i wrote before it will look and
> behave a little bit different...
Yes, I've never felt that code completion is a killer feature either, along
with it being difficult to implement for ruby. Fast access to the api docs
is more important because just knowing the name of a method via code
completion probably won't be sufficient to know how to use it.
Thursday
...
> But, there is one 'little' aspect that bugs me. Imo, the tools around a language will take it from a
> 'niche' and transform it to an 'big success'. While I see a lot of nice ideas put into different
> type framework, I cannot see any big effort going to an IDE.
> I am seeing some of them around:
> - Ruby support in vim
> - Ruby support in Emacs
> - Mondrian Ruby IDE
> - FreeRIDE
> - Arachno Ruby (I feel this is the only one going to the right direction ;-)),
>
> but none of them are at a level comparable with real IDEs (being them IDEs for Java, Python,
> C/C++/C#, etc). I am wondering why aren't the Ruby community considering this an important aspect?
Provide specific examples of 'real IDEs'.
Remember that some IDEs like CodeForge already support Ruby. By IDE,
did you mean
And there are programmer editors/ide with code-completion and class
browser that support ruby. For example, see:
http://www.zeusedit.com/ruby.html
If you're wondering about GUI programming, I'd recommend using
DialogBlocks 1.96 to design the GUI, export the GUI to xrc (xml rc) and
use that from Ruby with wxRuby.
Lothar Scholz
BG> Emacs and vi are astounding at editing text. I doubt there's anything out
BG> there that can do more. They also happen to have some pretty good support
BG> for a whole lot of different languages.
As a 10 year hardcore emacs user (and with my academic background in
user ergonomie) i think you are very wrong with this opinion.
Both are a little bit outdated and in many points there are now better
solutions.
Tomorrow i have to wait a few hours at the airport for my connect flight, maybe i'm
then in the right mood to participate in this religous war. Just to
set the first argument: Emacs is good text operating system, but it
lacks a good editor.
tsuraan
> most Ruby tools don't have a proper notion of a "Project"? PHP has a
> similar issue, but in Eclipse I can define a PHP project. It scans
> the source and presto completion works and so does a lot of other
> great stuff!
Not sure what a "project" is in this context, but I think the real
problem is that quite a few ruby libraries are rather dynamic: have a
look at soap4r and the recently launched classifier library. When you
use those, the methods that you're using most don't exist until
runtime; especially with soap it would be very difficult to do code
completion properly. I'm also a Ruby newby, so I can't say how common
runtime method additions are, but from what I've seen they are rather
popular, and they make code completion nearly impossible.
Guillaume Marcais
> On Thursday 28 April 2005 03:25, the_mindstorm wrote:
> > I have never been able to
> > use Emacs decently (this is probably only my fault), FreeRIDE is not
>
> See, that's the problem. When you *can* use Emacs or vi decently, the need
> for an IDE doesn't really seem to be there.
I am a little bit in the same boat. I regularly try Ruby editors/IDE.
But so far, they have not provided enough of an increase in features and
productivity that they justified to switch (and get used to a new
environment, work flow, key bindings, etc.). No religious thinking here,
the day I see a clear advantage in using an IDE for Ruby, I'll switch.
But for now Emacs does it for me.
That said, I sincerely hope great IDEs will emerge for Ruby.
Guillaume.
Alex the_mindstorm Popescu
>-----Original Message-----
>From: Austin Ziegler [mailto:halos...@gmail.com]
>How many of your 2000 classes are *useful* classes that do
>real work? How many of your 2000 classes are necessary because
>of the nightmare that is Java enterprise application
>programming? (When I looked at "Code Generation in Action", I
>was amazed at how many classes had to be generated for a
>single table/view combination.)
>
Are we questioning here the value of the project? Hmmm... I think this will not solve anything. But
if you want to go this way let's compaire:
No of. classes: (except generated code): aprox.2000
Total SLOC: aprox. 600k
Time of development: 5 years
Team: 10-12 people
Investment: aprox. 1.5 mil.$
Do we still compare? I think there no point in such a comparison. There is also no point in
comparing Java (language at choice) and Ruby capabilities. I was talking (in fact asking) about
editors/ides.
>Then you are interpreting this incorrectly, at least for Ruby.
>You can use any editor to work with Ruby.
Yes I know this. I am not talking about writing code in notepad ;-). Surely you can do that. But
efficiency is something very important.
>There is some
>support for Ruby in the major cross-language IDEs, but Ruby is
>a notoriously difficult language to provide full IDE capabilities for.
>
This is the point I have agreed from the beginning. Still I believe that with the right effort,
something can be done.
>
>Mmmm. I don't necessarily agree. An IDE can help, certainly,
>with things that are difficult to remember often. An IDE can
>also provide an environment for bad code. In the Java world,
>an IDE is almost certainly necessary to deal with the idiocies
>behind the library design. In the MS world, an IDE is almost
>certainly necessary to deal with the massive API set (and some
>of the idiocies behind the library design).
>
>In Ruby, I think that an IDE is much less necessary and
>useful. Code completion is very unlikely to be possible on a
>Ruby IDE, at least inasmuch as developers have come to expect
>with IDEs for statically typed languages.
>
>Can you point me to a Python IDE or three? I'd like to look at
>them to see if they come close to what VisualStudio can do, even, for
>C++.
>
I am not doing development with Python, but a branch of my co. is using Komodo (ActiveState if I
remember well) and they are happy with it. Take a look.
[Christian Neukirchen]
> Well, you obviously forgot that Java forces you to use one file per class (or did they change that
stupid requirement recently?).
>I couldn't deal with 2000 files in Emacs either, but 35 files and the same LOC would be no problem
(esp. as you focus on a handful at once >only). :-)
sorry I don't get you. I can obviously write down a 50k source, but is this the solution? No it is
not. Every language has its own stuff. I was not asking about doing Java dev with Ruby. Still I can
assume there are projects that are bigger than 50 sources.
[Ben Giddings]
I agree with many of the things you are saying. You could still use emacs for other stuff editing,
and still have a powerful Ruby env. Not everybody is switching languages all the time during
development. I was looking from this perspective.
[Thursday]
I am developing in Java (where I have a lot of choices), C++ (Visual Studio), a little Perl (vim,
but I know ActiveState has powerfull support here). I cannot enumerate any other languages and their
prefered envs, as I think this is mainly a personal stuff.
Let me explain my thoughts again:
1/ I am not questioning the power of a language vs its tool support. I think I can find good
points/bad points everywhere. Any ratio comparison will not help. There will be always very large
projects.
2/ I am not questioning the correctness of a project design.
3/ I agree dynamic typed languages are hard to support features from static typed languages. Pls
read John Wells' answer. There is value in there ;-).
4/ I see the power in vim (and believe the guys talking about Emacs power). I am only saying that I
feel something more can be done.
(I don't want to fall into that troll - Ilia stuff here. I am sorry I don't think/feel as you. At
any point you can say that I must stop and I will. I respect everybody and everybody's work).
Lothar Scholz
AtP> Are we questioning here the value of the project? Hmmm... I
AtP> think this will not solve anything. But
AtP> if you want to go this way let's compaire:
AtP> No of. classes: (except generated code): aprox.2000
AtP> Total SLOC: aprox. 600k
AtP> Time of development: 5 years
AtP> Team: 10-12 people
AtP> Investment: aprox. 1.5 mil.$
At the moment this is difficult. When i started my IDE i looked for
the largest available open source ruby project to use this as a sample
and try my ideas on this project. But i was not able to find anything larger
then a few dozens of files compressed to a gzip larger then
100 KB. The code densitiy of ruby and rails my be amazing at the first look but
i'm not sure how this would scale.
At the moment i don't think ruby is a good choice for projects of this
scale. My experience which such projects is that a lot of problems
come from changing persons during the development cycle. And thats
where every IDE is a huge improvement over a pure editor.
An IDE (and some methodology, coding conventions that must be
enforced) are very important if someone else must
read the code and extend code someone else has written.
This is just a different viewpoint then mostpeople in this forum have.
Because idoubt that many are working in larger teams on larger projects.
At least i never found team related comments/questions in the postings i read.
And don't think that my argument is that Arachno Ruby is that super
IDE that supports this right now. Thats why the version number is
still 0.5.x.
Aredridel
anything out
> BG> there that can do more. They also happen to have some pretty good support
> BG> for a whole lot of different languages.
I enjoy vi as part of a whole system.
gdb or ruby -rdebug for debugging. vi for editing. make and rake for
build automation. I assemble this small arsenal of tiny tools, and the
learning curve drastically shallows as I learn, because what works on
the shell works within vi (!!yourcommandhere), and the tools all work
together, because they have to, not out of explicit support for each
other.
Ari
Lothar Scholz
>> Isn't the thing that makes code completion difficult the fact that
>> most Ruby tools don't have a proper notion of a "Project"? PHP has a
>> similar issue, but in Eclipse I can define a PHP project. It scans
>> the source and presto completion works and so does a lot of other
>> great stuff!
t> Not sure what a "project" is in this context, but I think the real
t> problem is that quite a few ruby libraries are rather dynamic: have a
t> look at soap4r and the recently launched classifier library. When you
t> use those, the methods that you're using most don't exist until
t> runtime; especially with soap it would be very difficult to do code
t> completion properly. I'm also a Ruby newby, so I can't say how common
t> runtime method additions are, but from what I've seen they are rather
t> popular, and they make code completion nearly impossible.
You are right for things like SOAP or any other (distributed) technique
that simply dispatch message names. But we can handle the other case
more or less easily. My example is always TK as this builds a lot of
methods at runtime. In this cases you can simply dump the ruby code image
at the end of a script run and melt the information in this dump
with the data already in the repository. Method addition
is popular, method removal is not popular so it should work.
We are using a different type of language but too many people still
think in static terms. A completition popup can't look the same as in
java/C++ and the data gathering phase can't work with static source
code analysis alone. I'm not a mac guru, but follow apple and
"Think different"
kyu
One feature i find vi/nvi/vim/whatever is lacking is the ability to have
an interactive shell inside a buffer, i can be in
one xemacs session, and C-X2-C-Xo m-x shell and i have a command prompt
sitting right there, which i can even copy and paste from. I've never
found a way to do this in vi, and i find it much more productive to be
able to do everything from one terminal than constantly switching
backwards and forwards between processes. Just my $0.02 :)
Also, emacs can make a great ide with the code browser, which uses
semantic (and so supports ruby) and ruby-mode.el is great. :)
-kyu
Yohanes Santoso
> One feature i find vi/nvi/vim/whatever is lacking is the ability to
> have an interactive shell inside a buffer, i can be in
> one xemacs session, and C-X2-C-Xo m-x shell and i have a command
That's scary. Try this instead:
(defvar ys::eshell-wins nil)
(global-set-key "\C-cs" (lambda (win-num)
(interactive "p")
(message "win-num %s" win-num)
(let ((assoc-buffer (cdr (assoc win-num ys::eshell-wins))))
(if (not (buffer-live-p assoc-buffer))
(progn ; the requested buffer not there
(setq assoc-buffer (eshell t))
(setq ys::eshell-wins (assq-delete-all win-num ys::eshell-wins))
(add-to-list 'ys::eshell-wins (cons win-num assoc-buffer))))
(switch-to-buffer assoc-buffer)
(rename-buffer (concat "*eshell-" (int-to-string win-num) "*"))
assoc-buffer)))
To open shell #1: C-1 C-c s or if your environment doesn't transmit
C-<number> (like from a putty session), then use M-1 C-c s or the traditional C-u 1 C-c s
Shell #2: C-2 C-c s or M-2 C-c s or C-u 2 C-c s
and so on.
YS.
tsuraan
> have an interactive shell inside a buffer, i can be in
> one xemacs session, and C-X2-C-Xo m-x shell and i have a command
> prompt sitting right there, which i can even copy and paste from. I've
> never found a way to do this in vi, and i find it much more productive
> to be able to do everything from one terminal than constantly
> switching backwards and forwards between processes. Just my $0.02 :)
That's definitely a weak point of vim. There's a python script that
can put a shell in a vim buffer, but it's very unstable and nearly
useless. I've heard that the next version will have support for that,
but who knows... I mostly just code with multiple consoles and gpm, so
switching to a shell is just alt-f2 or whatever. It's still not nearly
as nice as emacs's integrated stuff though.
Martin DeMello
> >
> One feature i find vi/nvi/vim/whatever is lacking is the ability to have
> an interactive shell inside a buffer, i can be in
> one xemacs session, and C-X2-C-Xo m-x shell and i have a command prompt
> sitting right there, which i can even copy and paste from. I've never
> found a way to do this in vi, and i find it much more productive to be
> able to do everything from one terminal than constantly switching
> backwards and forwards between processes. Just my $0.02 :)
>
> Also, emacs can make a great ide with the code browser, which uses
> semantic (and so supports ruby) and ruby-mode.el is great. :)
Hopefully, the next version of vim will add more by way of embeddability
support, so that you can integrate a vim window as the editor component
of a larger app (I'd love to run vim within kate, for instance). A shell
within vim would be ideal, but vim within kate would be a decent
compromise for anyone using X.
martin
Martin DeMello
>
> In a C++ project that I am doing at work, there's a similar ratio.
> At any given time, I'm working with between three and fifteen files.
> I will use the VisualStudio environment for code completion and a
> few project-centric searches (it's a bit smarter than a text search
> that I do on Windows, but equally smart to a good find-grep search
> that I do on our Unix ports), and for integrated debugging, but
> that's about it. I do 95% of my code editing in vim.
FWIW, the workflow I've converged on here at work (~1M lines of visual
c++, though, as you say, seldom working on more than 5-10 files at any
given time) is gvim for editing, glark for searching and visual studio
for symbol lookup (better than ctags for its own projects) and compiling
(it lets you jump to errors).
martin
vruz
>
> Hopefully, the next version of vim will add more by way of embeddability
> support, so that you can integrate a vim window as the editor component
> of a larger app (I'd love to run vim within kate, for instance). A shell
> within vim would be ideal, but vim within kate would be a decent
> compromise for anyone using X.
>
> martin
>
>
http://www.freehackers.org/kvim/vimpart.html
or perhaps:
http://www.yzis.org
cheers,
vruz
Martin DeMello
> maybe you mean something like:=20
Sweet! Thanks for the pointers.
martin
Ralf Müller
Thomas Kirchner <li...@halffull.org> wrote:
> > t> 4/ autocompletion
> > Difficult in a dynamic language like ruby. We discussed this to death
> > in the past. Please use google.
>
> Obviously, this is incredibly difficult for ruby. However, when I've
> used IDEs in the past, this was exactly what I appreciated most. I think
> it'd be possible to get some basic autocompletion, skipping some of the
> more difficult dynamic elements, and most people would be happy, if not
> content.
Maybe you already know, but I'm very happy with this style of vim-autocompletition:
taken from my .vimrc:
" smart mapping for tab completion
function InsertTabWrapper()
let col = col('.') - 1
if !col || getline('.')[col - 1] !~ '\k'
return "\<tab>"
else
return "\<c-p>"
endif
endfunction
inoremap <tab> <c-r>=InsertTabWrapper()<cr>
" Dictionary completions
set dictionary-=/usr/share/dict/words dictionary+=/usr/share/dict/words
set complete-=k complete+=k
regards
ralf
Malte Milatz
> or perhaps:
> http://www.yzis.org
I'd really love to see something like this for Gnome and Ruby instead of
KDE and Lua - why is life so short?
Malte
Richard Dale
As it's a Kate part you can use it in KDevelop as well as Kate. I haven't
tried it though - I don't know if it has ruby syntax highlighting.
-- Richard
Jeff Barczewski
the past 3 years and I just love it. The Ruby plugin for jEdit is
beautiful. For me this Ruby jEdit plugin and RDT for Eclipse are the
best of what I have seen thus far.
On 4/28/05, Rob . <rob....@gmail.com> wrote:
> Method auto-completion for the core Ruby types will be in the next
> release of the Ruby Editor Plugin for jEdit, hopefully out in the next
> week. A documentation window will show next to the method list popup,
> so this will be a great tool for those new to Ruby. Alex, Ruby Editor
> Plugin pentru jEdit e cel mai bun*!
> http://www.jedit.org/ruby/
>
> What's missing from the Ruby IDE space is an editor let's you
> manipulate Ruby at the syntax level. For Java, modern IDEs let me
> think in terms like "method complete", "find declaration", "find
> usages", "extract variable", "rename member", "extract method",
> "change method signature", "go to last edit", "go to last location",
> etc. jEdit's Ruby Editor Plugin is evolving into this style of IDE.
>
> Not having to think about the more low-level textual manipulations
> frees your mind to make syntactical ones; obviously important in a
> verbose language like Java, but also of value to large-scale Ruby
> development projects.
>
> Cheers,
> Rob
>
> *Am lucrat pentru optspre luni in Timisoara. Stiu un pic Romaneste.
>
>
tony summerfelt
points:
>> C-X2-C-Xo m-x shell
and that's ALL you have to do to get a command line in emacs :)
> That's scary. Try this instead:
ok, but this is scarier:
> (defvar ys::eshell-wins nil)
> (global-set-key "\C-cs" (lambda (win-num)
> (interactive "p")
> (message "win-num %s" win-num)
> (let ((assoc-buffer (cdr (assoc win-num ys::eshell-wins))))
> (if (not (buffer-live-p assoc-buffer))
> (progn ; the requested buffer not there
> (setq assoc-buffer (eshell t))
> (setq ys::eshell-wins (assq-delete-all win-num ys::eshell-wins))
> (add-to-list 'ys::eshell-wins (cons win-num assoc-buffer))))
> (switch-to-buffer assoc-buffer)
> (rename-buffer (concat "*eshell-" (int-to-string win-num) "*"))
> assoc-buffer)))
one advantage is that vim has is that you can extend your editor using
the (or all for that matter) scripting language of your choice,
vimscript, tcl, perl, ruby, python. to extend emacs you use something
like have the lisp code above.
another advantage is that if you're a touch-typist, vim is very
efficient at editing code. i think it's very handy that to delete 5
lines of text you can type: 5dd or do it the long way: Vjjjjjd
compared to emacs: C-spacebar, cursor to your target, C-w
the first key combo assumes your terminal will support it otherwise
you're stuck with: M-x set-mark-command
--
http://home.cogeco.ca/~tsummerfelt1
telnet://ventedspleen.dyndns.org
Austin Ziegler
>> From: Austin Ziegler [mailto:halos...@gmail.com ]
>> How many of your 2000 classes are *useful* classes that do real
>> work? How many of your 2000 classes are necessary because of the
>> nightmare that is Java enterprise application programming? (When
>> I looked at "Code Generation in Action", I was amazed at how many
>> classes had to be generated for a single table/view combination.)
> Are we questioning here the value of the project?
No. What I'm questioning is how many of those 2,000 classes are
providing value to your project? Remember -- Java tends to require a
lot of "framework" code. Ruby requires much less. Ruby projects are
significantly smaller than Java projects that do similar things.
There was a comparison, recently, between a Java first-pass
implementation and a Ruby second-pass implementation. The Ruby one
was about a fifth the size, IIRC.
With this, the overwhelming need for an IDE for project management
is *reduced*. Not eliminated, mind you, but significantly reduced.
>> Then you are interpreting this incorrectly, at least for Ruby.
>> You can use any editor to work with Ruby.
> Yes I know this. I am not talking about writing code in notepad
> ;-). Surely you can do that. But efficiency is something very
> important.
Yes, and as yet, I don't think that many people have found the
heavyweight nature of an IDE to be beneficial to Ruby development.
This may change. When that happens
>> There is some support for Ruby in the major cross-language IDEs,
>> but Ruby is a notoriously difficult language to provide full IDE
>> capabilities for.
> This is the point I have agreed from the beginning. Still I
> believe that with the right effort, something can be done.
I doubt it, personally. Ruby will screw things up for just about any
IDE with the mere existence of #method_missing. On the other hand,
if Ruby had a system image -- like Smalltalk -- then it would be
easier. Not easy, mind you, but easier.
>> Can you point me to a Python IDE or three? I'd like to look at
>> them to see if they come close to what VisualStudio can do, even,
>> for C++.
> I am not doing development with Python, but a branch of my co. is
> using Komodo (ActiveState if I remember well) and they are happy
> with it. Take a look.
I remember playing with Komodo and being unimpressed. Maybe it's
been improved. I will look at it again.
> [Christian Neukirchen]
>> Well, you obviously forgot that Java forces you to use one file
>> per class (or did they change that stupid requirement recently?).
>> I couldn't deal with 2000 files in Emacs either, but 35 files and
>> the same LOC would be no problem (esp. as you focus on a handful
>> at once only). :-)
> sorry I don't get you. I can obviously write down a 50k source,
> but is this the solution? No it is not. Every language has its own
> stuff. I was not asking about doing Java dev with Ruby. Still I
> can assume there are projects that are bigger than 50 sources.
What he's saying is what I said, in part. In PDF::Writer, recently,
I did the following:
class SimpleTable
class Column
...
end
...
end
To do this in Java -- especially since Column is accessible as
SimpleTable::Column (it's a full blown class, not just a nested
class, if that's even possible in Java -- it's been a long time) --
I think that I'd have to do:
simpletable.java
class SimpleTable { ... }
simpletable/column.java
class SimpleTable.Column { ... }
Forgive me if I got the syntax specifics wrong. Because Column is
something that is specific to SimpleTable (but can be created and
used separately), I can define them in the same source file. It
keeps things conceptually closer together, whereas in Java, I have
to put them in separate files, which makes things *harder* to deal
with.
> Let me explain my thoughts again:
> 1/ I am not questioning the power of a language vs its tool
> support. I think I can find good points/bad points everywhere.
> Any ratio comparison will not help. There will be always very
> large projects.
> 2/ I am not questioning the correctness of a project design.
I disagree. I can far more easily deal with a logically structured
400-class Ruby project (especially since, as would probably happen,
I would factor out those 400 classes into as many libraries, utility
classes, and modules as possible) than a 2000-class Java project.
Let's play a mental game for a moment. With a database-bound
project, you will typically need several classes per table in Java,
each of which is pretty heavy-weight (some frameworks may *help*
with this, but they don't eliminate it, AFAIK). In Ruby, you will
still need a couple of classes (presentation, ORM, etc.), but the
main code can probably be factored out into modules and utility
classes. Look at ActiveRecord. I don't agree with its chosen
"correct" semantics, but it's an amazing class nonetheless.
If you're able to take the common code and make it dynamically
generable, or dynamically extendable, then you can factor out that
common code into a library *and maintain that library separately*.
That's big. That's bigger than big. And it indicates that both (1)
and (2) in your points *matter* as far as the need for an IDE is
concerned. If your language is powerful enough (1) to make it *easy*
to break the big project into smaller parts, then the project design
changes (2).
I don't use an IDE in Ruby -- even for some big projects that I'm
working on -- because I don't *need* an IDE in Ruby. When I *need*
an IDE in Ruby, then I'll start caring. And that's where I'm really
taking issue with what you're saying: so far, Ruby doesn't *need* an
IDE.
> 3/ I agree dynamic typed languages are hard to support features
> from static typed languages. Pls read John Wells' answer. There
> is value in there ;-).
This statement is, IMO, confused. (1) John Wells' answer works only
if you can logically run the application in the IDE. (2) Dynamically
typed languages tend to support far more than statically typed
languages, but are harder for things like IDEs to support.
> 4/ I see the power in vim (and believe the guys talking about
> Emacs power). I am only saying that I feel something more can
> be done.
Maybe. I think things are being done. Ruby offers a very different
development paradigm. It's like a conversation I was having with
someone on #ruby-talk the other day. The question was raised about a
module that requires a particular method to work. For example,
Enumerable requires #each.
This person's suggestion was (roughly -- this is my interpretation)
that there should be both Enumerable and IEnumerable.
class SubclassResponsibility < RuntimeError; end
module IEnumerable
def each
raise SubclassResponsibility
end
end
module Enumerable
include IEnumerable
end
This way, when I do:
class Foo
include Enumerable
end
If I try to use #inject I will get a SubclassResponsibility error.
There's a problem, though. If Foo is a delegator class that uses
#method_missing to do delegation, I have to *manually* define #each
so that I don't get SubclassResponsibility (or I have to undef
each). Enumerable shouldn't care that #each is *defined* --
Enumerable should care that it's responded to.
Why do I need an IEnumerable that enforces the idea of sub-class
responsibility? This thing that makes it supposedly "easier" for the
module developer makes it harder for the module user. What's hard to
understand about:
irb(main):006:0> foo.inject(0)
NoMethodError: undefined method `each' for #<Foo:0x2b5eb28>
from (irb):6:in `inject'
from (irb):6
This applies to both why Ruby doesn't -- yet -- *need* an IDE and
why an IDE would be nearly impossible to use, given what's possible
in redefining Ruby.
-austin
--
Austin Ziegler * halos...@gmail.com
* Alternate: aus...@halostatue.ca
Austin Ziegler
I'll have to play with glark, especially since it will work on our
other platforms, too. And you're right -- VS is better than ctags
for VS projects.
Dr Balwinder S Dheeman
Yes! kate has ruby syntax highlighting.
--
Dr Balwinder Singh Dheeman Registered Linux User: #229709
CLLO (Chief Linux Learning Officer) Machines: #168573, 170593, 259192
Anu's Linux@HOME Distros: Ubuntu, Fedora, Knoppix
More: http://anu.homelinux.net/~bsd/ Visit: http://counter.li.org/
Richard Dale
> On 04/29/2005 03:25 PM, Richard Dale wrote:
>> Martin DeMello wrote:
>>
>>
>>>vruz <horaci...@gmail.com> wrote:
>>>
>>>>maybe you mean something like:=20
>>>>http://www.freehackers.org/kvim/vimpart.html
>>>>
>>>>or perhaps:
>>>>http://www.yzis.org
>>>
>>>Sweet! Thanks for the pointers.
>>
>> As it's a Kate part you can use it in KDevelop as well as Kate. I haven't
>> tried it though - I don't know if it has ruby syntax highlighting.
>
> Yes! kate has ruby syntax highlighting.
Yes, but I meant the kyzis Kate plugin, not the standard Kate KPart.
-- Richard
Ruben
At Fri, 29 Apr 2005 21:44:54 +0900, tony summerfelt wrote:
>
> everytime the vim vs emacs thread comes up i like to make these two
> points:
>
> >> C-X2-C-Xo m-x shell
>
> and that's ALL you have to do to get a command line in emacs :)
Actually, if you just do M-x eshell, you already have a shell. The
other commands are just for splitting your window into 2 frames and
switching focus to the frame where you'll start the shell.
> ok, but this is scarier:
[snip]
What's so scary about lisp code? Wanna show me some vim-script?
> one advantage is that vim has is that you can extend your editor using
> the (or all for that matter) scripting language of your choice,
> vimscript, tcl, perl, ruby, python. to extend emacs you use something
> like have the lisp code above.
This is indeed great, the downside however is that on some
distributions, probably not all those languages will be enabled by
default (allthough i'm not sure about that), so that in the end
vimscript is the only way to be sure that your extensions will run
everywhere. There is no such problem with emacs-lisp-code. (unless you
want it to run on both GNU Emacs and Xemacs)
> another advantage is that if you're a touch-typist, vim is very
> efficient at editing code. i think it's very handy that to delete 5
> lines of text you can type: 5dd or do it the long way: Vjjjjjd
>
> compared to emacs: C-spacebar, cursor to your target, C-w
>
> the first key combo assumes your terminal will support it otherwise
> you're stuck with: M-x set-mark-command
Right, right.... but an experienced emacs user would probably just do
C-5 C-k. Which is for me faster than first switching mode in vim
(Esc), then do the 5dd, then switching back to insert mode (i).
What is the point of this "emacs is better" or "vim is better" ?
I use Emacs most of the time, but I regularly use vi(m) for editing
config files. I think the most important thing is that *you* can work
efficiently with the tools *you* use, whether your editor is Emacs,
Vi(m), a full-blown IDE...
Ruben
David Holroyd
> What he's saying is what I said, in part. In PDF::Writer, recently,
> I did the following:
>
> class SimpleTable
> class Column
> ...
> end
> ...
> end
>
> To do this in Java -- especially since Column is accessible as
> SimpleTable::Column (it's a full blown class, not just a nested
> class, if that's even possible in Java -- it's been a long time) --
FYI, the Java version of this construct would look something like,
/**
* TODO: Eclipse generated this comment, and I'll bet you can't
* work out how to stop this happening.
*/
public class SimpleTable {
/**
* HAHA: Got you again. To change comment generation
* settings, go to: Window -> Prefs -> Java -> Code ->
* Editor -> Layout -> Comments -> Autogeneration ->
* Templates -> Blah.
*/
public static class Column {
...
}
...
}
dave
--
http://david.holroyd.me.uk/
Austin Ziegler
> On Fri, Apr 29, 2005 at 10:26:38PM +0900, Austin Ziegler wrote:
>> What he's saying is what I said, in part. In PDF::Writer,
>> recently, I did the following:
>>
>> class SimpleTable
>> class Column
>> ...
>> end
>> ...
>> end
>>
>> To do this in Java -- especially since Column is accessible as
>> SimpleTable::Column (it's a full blown class, not just a nested
>> class, if that's even possible in Java -- it's been a long time)
>
> public static class Column {
> ...
> }
> ...
> }
Is that the same? You've got:
public class SimpleTable
public static class Column
What effect does the "static" have on SimpleTable::Column in Java?
David Holroyd
With the above definition, one could say,
SimpleTable.Column col = new SimpleTable.Column();
Without the 'static', instances of the inner class are associated (I
forget the appropriate terminology) with instances of the outer class.
This means for client code to construct a Column, it needs,
SimpleTable tab = new SimpleTable();
SimpleTable.Column col = tab.new SimpleTable.Column();
However, now, methods of Column can access member variables of the outer
SimpleTable class instance (the compiler synthesises an additional,
hidden 'this' reference in non-static inner classes, IIRC).
(The syntax *is* simpler when constructing a Column from an instance
method of the outer class.)
So, static inner classes behave the same as top-level classes, and
non-static inner classes exist to confuse the unwary.
dave
--
http://david.holroyd.me.uk/
Joe Van Dyk
I try to keep an open mind about trying new things all the time. But
I tried to use Emacs for two days and my wrists and hands hurt SOOO
bad that I had to go back to vim.
Do you have to bind the ctrl key to the caps lock key in order to use
Emacs over a long period of time?
Joe Van Dyk
Perhaps you mean something different, but wouldn't
!bash
work just fine in vim?
Although, I just have one gvim window open all the time and one
terminal running screen. Works for me.
Kent Sibilev
vim. That was my major problem with emacs. My wrists really hurt after
I started using my tiny laptop with small keyboard.
Kent.
Kent Sibilev
shell window and your buffers.
Kent.
On 4/29/05, Joe Van Dyk <joev...@gmail.com> wrote:
kyu
That's 1000000000000x better, thanks! :)
kyu
Err, in emacs to delete 5 lines i would type: C-u 5 c-k, which isn't
much longer than <Escape>5dd :)
Rob .
> I don't think that many people have found the heavyweight nature
> of an IDE to be beneficial to Ruby development. This may change.
I find the keybindings to syntactic-based code-navigation and
refactorings in modern Java editors very beneficial to development.
Implemented properly this feels quite natural and "lightweight". I'd
like to see the same features in Ruby editors.
> Ruby will screw things up for just about any
> IDE with the mere existence of #method_missing.
Programmers may find features like "type-based code-completion" and
"find declaration" are still valuable, even if these features don't
know about messages handled in #method_missing.
> I don't use an IDE in Ruby -- even for some big projects that I'm
> working on -- because I don't *need* an IDE in Ruby.
> ... Ruby doesn't *need* an IDE.
We don't have a syntactic-based editor for Ruby yet. I think for
anyone who's used one for Java will tell you they definitely *need* it
for development. Perhaps the same will be true for Ruby in the future
..
Kent Sibilev
that I *don't* need an IDEA like IDE for Ruby. I've been programming
Ruby since 2000 and vim is all I need.
Kent.
> ...
>
> Rob
> http://www.jedit.org/ruby/
>
>
Rob .
"We don't have a syntactic-based editor for Ruby yet. I think anyone
who's used one for Java will tell you they definitely *need* it for
have such an editor for Ruby ..."
Anyway, a diversity of approaches to Ruby editors like we have now can
only be a good thing for Ruby.
Kent Sibilev wrote:
> I'm using Intellij IDEA on my full-time job and I definitely can say
> that I *don't* need an IDEA like IDE for Ruby. I've been programming
> Ruby since 2000 and vim is all I need.
>
> Kent.
>
tsuraan
>
> !bash
>
> work just fine in vim?
What emacs lets you do is have a split screen, where one buffer is
running a console and the other buffer is editing code. In vim, you
can't do this. If you do :split and !bash (or :shell), the executed
program will completely replace vim, rather than just running in the
active buffer. Supposedly the next vim will let this sort of thing
work properly though.
>
> Although, I just have one gvim window open all the time and one
> terminal running screen. Works for me.
>
Yeah, I tend to do work in console mode, so one vim with splits and
vsplits (1280x1024 console), and a bunch of terminals work reasonably
well. Still, a properly embedded shell would be cool.
Tom Nakamura
On Sat, 30 Apr 2005 03:32:32 +0900, "tsuraan" <tsu...@xyons.net> said:
> Yeah, I tend to do work in console mode, so one vim with splits and
> vsplits (1280x1024 console), and a bunch of terminals work reasonably
> well. Still, a properly embedded shell would be cool.
"screen"-split at console (or simply multiple windows open) do not? I'm
not being sarcastic, i just want to know what i could be missing...
I also use this windows manager called "ratpoison" which takes care of
multiple windows for me flawlessly.
Austin Ziegler
> Austin Ziegler wrote:
>> I don't think that many people have found the heavyweight nature
>> of an IDE to be beneficial to Ruby development. This may change.
> I find the keybindings to syntactic-based code-navigation and
> refactorings in modern Java editors very beneficial to
> development. Implemented properly this feels quite natural and
> "lightweight". I'd like to see the same features in Ruby editors.
Refactoring in Ruby is a slightly different beast. (Well, truth be
told, it's a majorly different beast. I tend to be able to refactor
my code with simple :%s/oldname/newname/g). That said, the problem
of refactoring is being worked on, and it should (hopefully) be
independent of any IDE.
>> Ruby will screw things up for just about any IDE with the mere
>> existence of #method_missing.
> Programmers may find features like "type-based code-completion" and
> "find declaration" are still valuable, even if these features don't
> know about messages handled in #method_missing.
Type-based code completion is the very thing that will NOT work in
Ruby. It *can't*. The best you can get is a "statistically likely"
code completion that may break under a lot of circumstances.
Find declaration could be useful ... but, again, depends on type
information that is only available at runtime.
>> I don't use an IDE in Ruby -- even for some big projects that I'm
>> working on -- because I don't *need* an IDE in Ruby. ... Ruby
>> doesn't *need* an IDE.
> We don't have a syntactic-based editor for Ruby yet. I think for
> anyone who's used one for Java will tell you they definitely
> *need* it for development. Perhaps the same will be true for Ruby
> in the future ...
Doubtful, at least for the near future. Don't get me wrong -- Ruby
will benefit from certain IDE efforts. The inclusion of ri
information will be very useful if you can do that in the jedit Ruby
plugin. I have been playing with jedit and while I don't find it
nearly as usable as vim (long experience), it is an impressive
editor and I support what you're doing with the plugin.
But an IDE is very different.
IMO, a good Ruby IDE will support debugging; have ri and rdoc
information easily and quickly available, and that's about it.
Austin Ziegler
Stefan Lang
> > Hopefully, the next version of vim will add more by way of embeddability
> > support, so that you can integrate a vim window as the editor component
> > of a larger app (I'd love to run vim within kate, for instance). A shell
> > within vim would be ideal, but vim within kate would be a decent
> > compromise for anyone using X.
> >
> > martin
>
> maybe you mean something like:
AFAIK this project is abandoned :(
In older KDevelop versions you could select kvim as editor.
> or perhaps:
> http://www.yzis.org
This looks promising!
> cheers,
> vruz
Stefan
tsuraan
> "screen"-split at console (or simply multiple windows open) do not? I'm
> not being sarcastic, i just want to know what i could be missing...
Probably not a lot. Sometimes when I'm coding, I'll have the screen
arranged in quarters, and having one of those quarters be a console
would be useful. Being able to copy and paste from the console to
something that you're working on is nice (I tend to use gpm for this,
but using vim's copy-paste buffers would be more consistent). It's
nothing serious; I use vim full time, so I obviously don't consider it
to be a show-stopper. I'd just be really happy if having a console in
vim were possible.
Stefan Lang
> Martin DeMello wrote:
> > vruz <horaci...@gmail.com> wrote:
> >> maybe you mean something like:=20
> >> http://www.freehackers.org/kvim/vimpart.html
> >>
> >> or perhaps:
> >> http://www.yzis.org
> >
> > Sweet! Thanks for the pointers.
>
> As it's a Kate part you can use it in KDevelop as well as Kate. I haven't
> tried it though - I don't know if it has ruby syntax highlighting.
It has the same syntax highlighting files as Kate, including one for Ruby.
> -- Richard
Stefan
Ara.T....@noaa.gov
open up a screen session (man screen) and you can have both a console and vim
in alternating screen with cut-and-paste between them. i use it all the time:
one window with vim, one running code/tests, one in console.
something like this will get you going:
~ > screen -S my_screen_name # start a screen with a name
~ > vim a.rb # open up vim in first window
~ > Ctrl-a c # create a new console in this terminal
~ > Ctrl-a n # switch back to your vim
do a Ctrl-a ? for help and/or man screen to read about cutting-pasting. this
also has the advatange that you can login to the machine from another host
(when you go home for instance) and re-attach to your screen and you'll be
exactly where you were in your vim session before. this one is tough to do in
an ide!
cheers.
-a
--
===============================================================================
| email :: ara [dot] t [dot] howard [at] noaa [dot] gov
| phone :: 303.497.6469
| renunciation is not getting rid of the things of this world, but accepting
| that they pass away. --aitken roshi
===============================================================================
llothar
is necessary. Code coverage also, especially when integrated together
with unit testing. Project based settings are important. Good version
control integration and a much improved irb. Better handling of
multiple files (when you have 300 files in a project editors become
very hard to use). Interation of a HTTP testing framework and a lot of
other things....
Ruben
At Sat, 30 Apr 2005 01:35:57 +0900, Joe Van Dyk wrote:
>
> I try to keep an open mind about trying new things all the time. But
> I tried to use Emacs for two days and my wrists and hands hurt SOOO
> bad that I had to go back to vim.
I've heard before that some people have this problem...
> Do you have to bind the ctrl key to the caps lock key in order to use
> Emacs over a long period of time?
No, I never did that. I've read that some people do that, but I never
felt the need for that; I never had any problems with my wrists.
Also, for most shortcuts I'm using the right Ctrl-key instead of the
left one, maybe that helps (since I'm using both hands instead of
one).
Ruben
tony summerfelt
> What's so scary about lisp code? Wanna show me some vim-script?
personally i don't think it's scary... i don't really have a problem
with vimscript either
> This is indeed great, the downside however is that on some
> distributions, probably not all those languages will be enabled by
> default
there's a good chance that NONE of them will be. on linux that's not
really a problem, i think most intermediate linux users could easily
compile vim with perl (or the others) enabled...
on windows it's much easier to google around till you find vim with
the language you want already compiled in...but it's not that
difficult to compile in windows either...
> vimscript is the only way to be sure that your extensions will run
> everywhere.
i wasn't thinking of distributing extensions. i was thinking of the
programmer using vim extending the editor him/herself in the language
(probably) already being used ie. ruby.
if for some reason i thought my vim extension should be distributed,
i'd make the proper vim exe available anyway...
> Right, right.... but an experienced emacs user would probably just do
> C-5 C-k. Which is for me faster than first switching mode in vim
> (Esc), then do the 5dd, then switching back to insert mode (i).
i'm just guessing here, but i think most vim users switch in and out
of the various modes less then one would think...
combo commands i tend to use in frequently that require command mode,
i've already mapped to something else...
very rarely do i have to hit esc. other vim users' mileage may very...
> I use Emacs most of the time, but I regularly use vi(m) for editing
> config files.
i was a die hard emacs user until i had to work on other linux
boxes...to make my life easier i just bit the bullet and learned vim
because i knew some version of it would be on the system... of course
once i learned vim i didn't really need emacs anymore. i do have a few
emacs like editors installed though (microemacs, jed) just in case i
get the urge :)
> I think the most important thing is that *you* can work
> efficiently with the tools *you* use, whether your editor is Emacs,
> Vi(m), a full-blown IDE...
true enough...i was mainly thinking from the newbies point of view
when thinking of the choice to use an editor or an ide
20 years ago we had an ide for just about every dos language (turbo
pascal, turbo c, quickbasic, etc) you got used to it... which is
probably why plugins for various ide's like eclipse, jedit, are
popular now...
having said all that, i use komodo for my ruby programming beyond 100
lines or so. if i need to debug beyond 'print statements' i fire up
freeride.
--
http://home.cogeco.ca/~tsummerfelt1
telnet://ventedspleen.dyndns.org
tony summerfelt
> Err, in emacs to delete 5 lines i would type: C-u 5 c-k, which isn't
> much longer than <Escape>5dd :)
it's not the length so much as it's the hand and finger contortions.
the example in question isn't that bad, but i've had to do worse...
with vim your hands don't have to travel far from the home row...
<esc> would of course be typed with ctrl-[
if one is a touch-typist, vim makes you very efficient at editing text...
William Morgan
> what features do a "properly embedded shell" have that a simple
> "screen"-split at console (or simply multiple windows open) do not?
> I'm not being sarcastic, i just want to know what i could be
> missing...
For languages with an interactive environment (like Ruby (irb) and R), a
good Emacs mode will let you run the environment in a split screen with
the code you're editing, and will make it easy to dump the current
line/selection/function into the environment.
I haven't figured out how to do this with Ruby yet, but with R I just
hit C-c M-f and whatever function the cursor is currently in gets dumped
into the interactive environment and evaluated. Makes debugging easy.
--
William <wmorgan-...@masanjin.net>
Michael Campbell
> if one is a touch-typist, vim makes you very efficient at editing text...
And if all you want to do is edit text, vi(m) is a fine editor.
Emacs big win is that it does so, so much more. It's like debating
your clock vs. your computer because you can tell the current time
with both.
And, I apologize for adding to this way too off topic thread.
mark sparshatt
You can do this using inf-ruby.el
When in ruby mode it adds a command run-ruby which runs irb in a sub
window and then allows you to copy code into it.
HTH
--
Mark Sparshatt
William Morgan
> this also has the advatange that you can login to the machine from
> another host (when you go home for instance) and re-attach to your
> screen and you'll be exactly where you were in your vim session
> before. this one is tough to do in an ide!
Well now. This is about the most useful thing I've seen all year.
Thanks, Ara!
--
William <wmorgan-...@masanjin.net>
Ara.T....@noaa.gov
no problem - my sysad actually showed it to me. i don't know how i ever lived
without it!
Lyndon Samson
> >
> > if one is a touch-typist, vim makes you very efficient at editing text...
>
> And if all you want to do is edit text, vi(m) is a fine editor.
>
> Emacs big win is that it does so, so much more. It's like debating
> your clock vs. your computer because you can tell the current time
Huh? http://www.vim.org/scripts/index.php Maybe not on a par with
emacs, but pretty impressive, and you can script it with ruby, so it
kicks emacs ass all over the place for that.
I've disliked the whole Wordstar/Ctrl Key paradigm even since I got
trapped in such an editor on a 1200/75 dialup modem connection once
many years ago...scary :-)
> with both.
>
> And, I apologize for adding to this way too off topic thread.
>
>
--
Into RFID? www.rfidnewsupdate.com Simple, fast, news.
Aredridel
> an interactive shell inside a buffer, i can be in
> sitting right there, which i can even copy and paste from. I've never
> found a way to do this in vi, and i find it much more productive to be
> able to do everything from one terminal than constantly switching
> backwards and forwards between processes. Just my $0.02 :)
That's what C-z is for!
Ari
Aredridel
I actually like switching processes, I don't know why.
Christian Neukirchen
Except vim won't interpret that if in insert mode, or is that configurable?
--
Christian Neukirchen <chneuk...@gmail.com> http://chneukirchen.org
tony summerfelt
>>if one is a touch-typist, vim makes you very efficient at editing text...
> And if all you want to do is edit text, vi(m) is a fine editor.
all my code is text so yes, i want to edit it efficiently.
it did occurr to me though that people might not know what
'touch-typist' meant.
> Emacs big win is that it does so, so much more.
true enough. i don't want my editor checking my email, just editing
text shaped like code.
> t's like debating your clock vs. your computer because you can tell
> the current time with both.
most people don't want a computer on their wrist though :)
i DO have emacs set up with w3, reading newsgroups, email, gdb,
etc...because i COULD :) i just don't use it that often
jus...@zeusedit.com
> By IDE, did you mean
>
> And there are programmer editors/ide with code-completion and class
> browser that support ruby. For example, see:
>
> http://www.zeusedit.com/ruby.html
And with the following extra download Zeus will also do Ruby code
folding:
http://www.zeusedit.com/forum/viewtopic.php?t=109
Jussi Jumppanen