. . . although, the editor question *does* have some relevance for people
who want some idea of the relative merits and failings of various editors
when they are assessing the best options for what to use while writing
Ruby code.
On Thu, Jun 02, 2011 at 03:09:06AM +0900, Wilde, Donald S wrote:
Jeez... BSD or Linux... or Doze?
Enough already... back to our regularly scheduled Ruby questions!
--
Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]
I think it depends on what you are going to be doing with Ruby. For rails I
would probably give in and just use an IDE as I have had nothing but
problems getting Emacs rails plugins to work just right. The IDE just makes
things easier when it comes to navigating between all the files in a Rails
application. Now if we are talking about just plain old Ruby Emacs (Or that
redheaded child called Vim.) will work quite well. One IDE I do like quite
a bit is Aptana Studio. Mostly stays out of the way and helps me remain
productive. Though it does have some odd bugs.
Another good IDE to try is Netbeans as others have mentioned. I am still a
bit upset that the Ruby plugin is no longer officially supported, the
effectiveness of the plugin left little to be desired for me.
OMG! Developing finally becomes real fun again. Thank you so much! It
really speeds up developing, especially since I switched to the common
two spaces for a tab now (my eyes are trained to four spaces) it saves
my a lot time. Again, thanks for the hint!
- Markus
On 01.06.2011 01:13, Marc Weber wrote:
Excerpts from Markus Fischer's message of Wed Jun 01 00:42:03 +0200 2011:
begin/class/etc. and closing end. Would love be proved otherwise here.
get matchit.zip !
Thet let's you dynamically add more pairs using b:match_words which
should already be implemented for ruby.
(I recommend using vim-addon-manager for installing plugins)
Excerpts from Stephen Boesch's message of Wed Jun 01 01:36:28 +0200 2011:
opinions on redcar?
Are you asking me ? No - never used it.
Vim is powerful due to its modal editing.
However also Netbeans etc have Ruby support and Vi like keybindings.
So it also depends on what will done - eg whether rails support is
required etc.
Marc Weber
I'm using Redcar and I love it. It doesn't stand in your way while
coding but provides a lot of useful features (it has problems, tough.
E.g. Redcar relies for many things on xulrunner, but can't use a
xulrunner >= 2.0.0). I'm currently trying to familarize with emacs, but
the default colors it uses for Ruby syntax highlighting are really ugly.
Any way to change them?
Note that Redcar is still alpha; while this means it's unstable and
sometimes crashes, it also means that new features get added each release.
Vale,
Marvin
Am 01.06.2011 01:36, schrieb Stephen Boesch:
opinions on redcar?
opinions on redcar?
I like it. It is also one of the few editors that is fast and totally cross
platform. It has good syntax highlighting for things like Haml & Cucumber
steps. Maybe that has improved recently, but redcar had it early on.
On Wed, Jun 1, 2011 at 12:36 AM, Stephen Boesch <javadba@gmail.com> wrote:
2011/5/31 Marc Weber <marco-oweber@gmx.de>
> Excerpts from Markus Fischer's message of Wed Jun 01 00:42:03 +0200 2011:
> > begin/class/etc. and closing end. Would love be proved otherwise here.
>
> get matchit.zip !
> Thet let's you dynamically add more pairs using b:match_words which
> should already be implemented for ruby.
> (I recommend using vim-addon-manager for installing plugins)
>
> Marc Weber
>
>
--
http://richardconroy.blogspot.com | http://twitter.com/RichardConroy
You made your point succinctly and eloquently Chad.
I do find it interesting that the topic of text editors becomes a
passionate debate even after all these years. I discovered the Z shell
about 6-7 years ago after a two year stint with bash and previously
worked exclusively with (t)csh and (a)sh.
After discovery of zsh I immediately contacted my buddy who I wanted
to share the joy with whom had been using bash since it's release.
His response was ultimately pragmatic. He felt that he had been using
bash so long that it made no sense for him to switch. I respect that
view.
vi as all good unix utilities builds on the concept that everything is
built from knowledge from the previous tools.
For example if you follow the tool of how shell programming evolved
before perl broke the single command does one thing and one thing
well:
ed => grep => sed => awk ----> perl and now ruby
each one of these builds on the concepts of the previous( much the
same way the shell has evolved). Most of us prefer it because it is on
every unix system so it's always available in some form or another.
vim has many plugin's that can make it act like just about any ide
like environment. Support for syntax highlighting in over 3000
languages, programs, and frameworks. Built in regex and (s)ed style
features in ex. Macros, automation and scripting. They even have
auto-completion.
Ultimately unless someone has been stuck using a closed source editor
or any closed software over an extended period of time they might find
it difficult to switch. Essentially every user has a preference based
on their skill and will prefer the tools that they have hit an apex
with.
Sticking with open source editors( even the GUI ones) in any form will
at least get the user the empowerment and freedoms we all enjoy
working with these tools.
I imagine Stillman's vision wont truly be realized until hundreds of
years after his death where closed source editors and tools will have
hit EOL time and time again while the open source editors based on the
editors of the mid 70's will still be highly developed and in heavy
use for whatever programming is done in that era. Talk about leaving
your legacy.
On Wed, Jun 1, 2011 at 1:19 PM, Chad Perrin <code@apotheon.net> wrote:
On Thu, Jun 02, 2011 at 03:09:06AM +0900, Wilde, Donald S wrote:
Jeez... BSD or Linux... or Doze?
Enough already... back to our regularly scheduled Ruby questions!
. . . although, the editor question *does* have some relevance for people
who want some idea of the relative merits and failings of various editors
when they are assessing the best options for what to use while writing
Ruby code.--
Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]
xulrunner >= 2.0.0). I'm currently trying to familarize with emacs, but
the default colors it uses for Ruby syntax highlighting are really ugly.
Any way to change them?
It's emacs you can change everything. The easy way just install themes
and select which you like.
Emacs is great for ruby, but it does have a learning curve to it. The
simplest two free editors to get up and running with are Jedit and
Geany. If you want to pay about $60 then this has every feature
imaginable The Ruby on Rails IDE by JetBrains
Sayth
Let me add to this thread that the editors of dedicated IDEs are
generally speaking light-years more aware of their target than vim or
emacs. And I have been an emacs user for years.
So, if you want to work with Java, nothing beats IDEA, and no amount
of plugins will give you RubyMine for Rails.
I am talking editors, not integrated environments. I mean, most people
assume working with an IDE means that you're expected to run rake
tasks within the IDE and launch web servers. Well IDEs provide that,
but you can use an IDE for its powerful editor, and be a console guy,
that's my case.
When I am going to work in the same Rails application for the whole
day, I launch RubyMine and a console. Only use lighter editor for
casual editing nowadays.
Sometimes people say "baahh, IDEs, I don't an integrated environment",
and then they go and install a dozen plugins for their favorite editor
to be able to have... an integrated environment! Only, it is never
that complete. This argument is for me kinda a Greenspun's Tenth Rule
for editors.
Of course, working with vim or emacs has a ton of advantages, and a
lot of people prefer them. That's fine I am not saying they shouldn't.
But if you want a powerful editor for technology T and there's a good
IDE for T out there, its *editor* is going to be really smart about T.
Let me add to this thread that the editors of dedicated IDEs are
generally speaking light-years more aware of their target than vim or
emacs. And I have been an emacs user for years.
I think that the idea of equating tight coupling with superiority is
deeply flawed. Flexibility and composability have, in my experience,
proved significantly more important and empowering than tight coupling.
This is just one reason among many that I prefer vi-like editors over big
IDEs. Unfortunately, there are cases where, in essence, the language one
uses is nigh-unusable on its own for nontrivial projects, as in the case
of Java (at least relative to languages like Ruby). Because of this,
their demand for tools that do a lot of the work for you is significant,
which means you need to focus more on tools that know the language than
on tools that aid productivity by helping you edit code more efficiently.
Ruby has proven to have nowhere near that kind of difficulty associated
with its use, for me. This is one reason of many that I like it. I can
use a vi-like editor, focusing on writing and editing code rather than on
getting the editor to write the scaffolding and boilerplate I need, and
to help me look up complex chunks of code needed to achieve basic
functionality.
I am talking editors, not integrated environments. I mean, most people
assume working with an IDE means that you're expected to run rake
tasks within the IDE and launch web servers. Well IDEs provide that,
but you can use an IDE for its powerful editor, and be a console guy,
that's my case.
Apart from stuff like "Intellisense" and code generation, there isn't a
whole lot the bare editor part provides that Vim doesn't -- and Vim
actually has an Intellisense-like plugin now. There's a certain amount
of code generation that could be arranged even with basic functionality,
too. What are these magical capabilities of *just* the editor that IDEs
provide above and beyond the capabilities of something like Vim?
When I am going to work in the same Rails application for the whole
day, I launch RubyMine and a console. Only use lighter editor for
casual editing nowadays.Sometimes people say "baahh, IDEs, I don't an integrated environment",
and then they go and install a dozen plugins for their favorite editor
to be able to have... an integrated environment! Only, it is never
that complete. This argument is for me kinda a Greenspun's Tenth Rule
for editors.
Note, by the way, that while I pointed out there's an Intellisense-like
plugin, I don't use it. I don't *need* it. Ruby is neither Java nor C#.
It isn't C++, VisualBasic, or any of a few dozen other languages with
similar complexity issues. Sure, there's a lot to Ruby, but it requires
much less . . . *management* than what comes with those other languages.
Y'know what I have for plugins? Nothing. Not a damned thing. The one
thing I actually integrate with Vim for coding in Ruby is irb, via the
interactive_editor gem.
By the way, the reason you have to create an informally specified, buggy
implementation of Lisp when writing nontrivial programs in other
languages (according to Greenspun's rule) is not because Lisp comes with
crap tons of features piled on top. It's because Lisp has a simple,
elegant semantic form that provides incredible power and flexibility
belied by that simplicity. That's shockingly similar to how the core
vi-like experience works: a simple, elegant semantic form (relative to
IDEs, anyway) that provides incredible power and flexibility belied by
that simplicity. Vim throws a lot of features on top of the vi-like
editor experience, most of which I really don't need, but the center of
the experience helps.
That's not to say that IDEs should not be used. Especially for C#, Java,
and other languages in that category of unmanageable complexity, IDEs are
very useful. They can be very useful for Ruby as well -- especially if
Ruby is being written by someone who is not familiar with editors like
Vim and Emacs, and especially if dealing with very complex frameworks.
They are certainly not *necessary* for Ruby coding, though, nor even
preferable for many developers, even when dealing with those very complex
frameworks. Maybe an IDE works better for *you* than Vim, but certainly
not for me.
Of course, working with vim or emacs has a ton of advantages, and a
lot of people prefer them. That's fine I am not saying they shouldn't.
But if you want a powerful editor for technology T and there's a good
IDE for T out there, its *editor* is going to be really smart about T.
Yeah, maybe so -- but the smoother the development experience provided by
the language itself, the less smart about the language the editor needs
to be to provide a roughly ideal experience programming in that language.
Ruby is definitely among the top 10 languages I've seen for a smooth
development experience.
On Thu, Jun 02, 2011 at 06:35:40AM +0900, Xavier Noria wrote:
--
Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]
[snip]
I strongly agree there, Chad. Last fall I built an entire target stimulation environment with a full wxWidgets GUI that launched half a dozen extra processes for target instrumentation through telnet that talked through shared memory, and I never once missed a debugger. Whole thing was edited with SciTE. Ruby just is too easy to figure out. 
Now I'm being forced into C++, and I just can't do it without a full debugger. As good as Eclipse is, I find myself really missing the class-browsing tools I had with Smalltalk 20 years ago. C++ is really difficult to keep from straying into syntactic nightmares, especially when they're somebody else's syntax. THAT's where you need a really top-shelf IDE.
About the only tool I'd like to have for Ruby over and above basic editing is a refactoring class browser; that'd be a nice tool to have. OTT just a seamlessly slick little editor and I'm happy. Any of the aforementioned will do.
Which is why I REALLY want to get Ruby ported to my little target, so if anyone has a clue as to how I can get past the little linker bugaboo that has make failing to pass a symbol file name to ld...
-----Original Message-----
From: Chad Perrin [mailto:code@apotheon.net]
Sent: Wednesday, June 01, 2011 4:12 PM
To: ruby-talk ML
Subject: Re: What editor or IDE do you use?
Ruby has proven to have nowhere near that kind of difficulty associated with
its use, for me. This is one reason of many that I like it. I can use a vi-
like editor, focusing on writing and editing code rather than on getting the
editor to write the scaffolding and boilerplate I need, and to help me look
up complex chunks of code needed to achieve basic functionality.
I wish I could help, but that's beyond my areas of expertise.
I find stories like yours about what people have done with Ruby, without
needing the heavyweight support tools that are part of daily life with
languages like C++, interesting -- and, of course, it's always nice to
have my sense of working with the language confirmed by others' similar
experiences.
On Thu, Jun 02, 2011 at 08:35:33AM +0900, Wilde, Donald S wrote:
Which is why I REALLY want to get Ruby ported to my little target, so
if anyone has a clue as to how I can get past the little linker bugaboo
that has make failing to pass a symbol file name to ld...
--
Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]
Well, the argument "since Ruby is not as heavyweight as Java or C++,
there's no need for an IDE, I've been doing well with simple editor
X!" is flawed for me.
I've been doing Perl with CPerl for years, and Ruby with TM for
years. There's still room for a ton of help. There's a negative space
you don't see out there. That's why people come with plugins, because
once you have the help of snippets, or once you know how helpful is
being able to jump from action to view, or from model to test case,
then you value that and want that extension.
Your reaction is not: "Ruby is simple, I can type
validates_presence_of myself no prob". Your reaction rather is "ah,
albeit Ruby is simple, that's still helpful!". That "ah" moment
happens a lot working with a Rails-aware editors like RubyMine. The
first day I saw renaming a controller renamed all the folders, tests,
etc. for you and updated the repo with the changes if you wanted, I
was sold. The day you make a typo in the table name of add_index and
gets underlined in red, you say "ah, Ruby is simple, but that's
helpful". And same with a ton of Rails-specific features (have little
experience with Ruby-only projects in RubyMine, there's support but
have not used it).
If you could have those features in Vim you'd like them. People prefer
Vim in spite of not having them because in their pros and cons list
they value other stuff. Like being able to use it for everything (I
can't do Perl with RubyMine), extensibility, speed, memory usage, etc.
I understand that and that's fine of course.
But saying "Ruby is simple, we do not need much help" is flawed, when
you get help you value it. And that's why people install a dozen
plugins, to get as much help as possible. (And sometimes people don't
because it gives the feeling of an aggregation of stuff to some and
prefer a lean environment.)
One of the things I've been watching more and more as systems and web programming matures is the way that doing a job right requires multiple programming languages. UNIX started it with awk and sed and TeX mixed in with shell script, and the Web almost requires JavaScript on top of whatever else you use. One area where Rails is definitely 'done right' is in its wrapping of database functionality. If you want to have nightmares, just take a quick glance at the Zend framework. (I'm not kidding, you WILL have nightmares) Such multi-lingual programming takes you beyond any IDE really quickly.
C++ is a really special case. It's the only language I know which has multiple distinct layers of syntax within itself, and that helps make it really opaque when reading someone else's code. If their idioms are different than yours, look out!
Thanks for the commiseration, Chad. It's beyond my expertise too, but I'm about to the point where I'm going to have to become an expert if I want it to fly.
-----Original Message-----
From: Chad Perrin [mailto:code@apotheon.net]
Sent: Wednesday, June 01, 2011 10:13 PM
To: ruby-talk ML
Subject: Re: What editor or IDE do you use?
On Thu, Jun 02, 2011 at 08:35:33AM +0900, Wilde, Donald S wrote:
Which is why I REALLY want to get Ruby ported to my little target, so
if anyone has a clue as to how I can get past the little linker
bugaboo that has make failing to pass a symbol file name to ld...
I wish I could help, but that's beyond my areas of expertise.
I find stories like yours about what people have done with Ruby,
without needing the heavyweight support tools that are part of
daily life with languages like C++, interesting -- and, of course,
it's always nice to have my sense of working with the
language confirmed by others' similar experiences.
[snip]
Your reaction is not: "Ruby is simple, I can type
validates_presence_of myself no prob". Your reaction rather is "ah,
albeit Ruby is simple, that's still helpful!". That "ah" moment
happens a lot working with a Rails-aware editors like RubyMine. The
first day I saw renaming a controller renamed all the folders, tests,
etc. for you and updated the repo with the changes if you wanted, I
was sold. The day you make a typo in the table name of add_index and
gets underlined in red, you say "ah, Ruby is simple, but that's
helpful". And same with a ton of Rails-specific features (have little
experience with Ruby-only projects in RubyMine, there's support but
have not used it).
[snip]
I totally agree that Rails is much more usable with a Rails-aware IDE as you say.
My HO is that Rails is about as far from a programming language as it's possible to get (in its own good way). The structures of directories, helpers, rules in configuration and method naming conventions are so distributed that keeping them current is almost impossible without a very tightly integrated IDE. Especially if you don't live and breathe Rails in your dreams.
I stopped using RoR completely when it became apparent that there was no way to pick a stable point (say 2.2) and build from there. Rails is so much of a moving target -- and it's guaranteed that somebody is always using a component that is newer than your stable point -- that it becomes impossible to use as less than a full-time occupation.
MHO is that I wish the Rails team would adopt a two-track model, where new packages are back-ported to -STABLE as well as -BLEED unless they only work with -BLEED features, but of course the FOSS answer is "if you want it, DIY" and I am grateful for the fact that it exists so folks who can devote full time to it can develop such amazing web systems.
Ruby itself is so intuitive that debugging with puts is sufficient, but I'll agree that refactoring (or renaming, such as you suggest) is an area where I'd like to have support. I've found that Ruby's built-ins -- especially its containers and iteration mechanisms -- are so powerful and elegant that very little code gets beyond a page.
-----Original Message-----
From: Xavier Noria [mailto:fxn@hashref.com]
Sent: Thursday, June 02, 2011 12:19 AM
To: ruby-talk ML
Subject: Re: What editor or IDE do you use?
Well, the argument "since Ruby is not as heavyweight as Java or C++,
there's no need for an IDE, I've been doing well with simple editor
X!" is flawed for me.I've been doing Perl with CPerl for years, and Ruby with TM for
years. There's still room for a ton of help. There's a negative space
you don't see out there. That's why people come with plugins, because
once you have the help of snippets, or once you know how helpful is
being able to jump from action to view, or from model to test case,
then you value that and want that extension.
. . . for a while. Just as I thought Dreamweaver, then Homesite, was
great for a while but eventually went back to plain ol' text editors when
I realized they were in my way more than I helped, I have done the same
with IDEs for languages that are not too incoherent and complex in their
implied development models to get work done efficiently without an IDE.
After a while, the IDE becomes "the language", and effort is spent
learning and using the tool rather than the language itself. While
vi-like editors are very powerful tools -- as powerful as any IDE out
there, I would say, when used within the context of a developer enabling
environment like the Unix userland -- they are essentially *transparent*
tools; they do not obscure the language behind their abstractions,
diverting my attention from the language with their features. This is,
to a significant degree, what I value most about them.
Dealing too much with an editor's gizmos is a distraction from the code,
as a trade-off for the convenience those gizmos provide. Getting into
"the zone", as one might call it, becomes very difficult because the
language does not disappear from conscious view by way of a nearly
intuitive grasp of it; it is obscured from view by way of a conscious
attention on the tools for dealing with it.
IDE: I don't really see the language any longer. I just see drop-down
lists, completion widgets, MVC organizational hierarchy trees, variable
and class managers. . . .
Vim: I . . . I don't even see the code. All I see is blonde, brunette,
red-head. Hey, you uh . . . want a drink?
Your reaction is not: "Ruby is simple, I can type
validates_presence_of myself no prob". Your reaction rather is "ah,
albeit Ruby is simple, that's still helpful!". That "ah" moment
happens a lot working with a Rails-aware editors like RubyMine. The
first day I saw renaming a controller renamed all the folders, tests,
etc. for you and updated the repo with the changes if you wanted, I
was sold. The day you make a typo in the table name of add_index and
gets underlined in red, you say "ah, Ruby is simple, but that's
helpful".
Actually, my reaction is "I've been using this for a while, and it seemed
helpful at first, but I've eventually discovered this is in my way, a
distraction from the real work," or "This provides a little bit of value,
but the trade-off that comes with using this instead of that is too high
a price to pay."
It's not like I've never tried IDEs or plugins for Vim.
Things like moving or changing the names of large numbers of files,
directories, and so on, are as easily accomplished using the basic tools
in my working environment as using an IDE.
And same with a ton of Rails-specific features (have little experience
with Ruby-only projects in RubyMine, there's support but have not used
it).
This might be part of the disconnect between us; I do a lot of Ruby-only,
or (more accurately) Ruby-plus-stuff-that-isn't-Rails. I alluded to the
complexities of Rails being akin to those of languages like C++, to some
extent; its magic is a bit like the impenetrable depths of C++ in the way
that it's getting to be effectively impossible to hold a complete
understanding of how things work in one's head. While I would happily
use Rails and improve my facility with it for the right client or
employer, outside of such requirements I prefer to do my work without it,
because while I like tools that give me additional leverage, I prefer
tools that are meant to be understood by mere mortals, rather than
employed as an act of faith.
If you could have those features in Vim you'd like them. People prefer
Vim in spite of not having them because in their pros and cons list
they value other stuff. Like being able to use it for everything (I
can't do Perl with RubyMine), extensibility, speed, memory usage, etc.
I understand that and that's fine of course.
I mentioned a couple of those things, but you seem inclined to ignore
that in favor of telling me I don't know what I'm talking about.
But saying "Ruby is simple, we do not need much help" is flawed, when
you get help you value it. And that's why people install a dozen
plugins, to get as much help as possible. (And sometimes people don't
because it gives the feeling of an aggregation of stuff to some and
prefer a lean environment.)
. . . except when that "help" is more illusion than reality. Facility
with a language, with a particular development workflow, and with a
particular model of software development makes a lot of the stuff one
would get with an IDE or piles of plugins *redundant*, or even
counterproductive because bad automation sometimes does things wrong.
Bad automation is the stuff that tries to make my decisions for me. Good
automation makes execution of my decisions easier. An editor that
"knows" the language on a semantic level is an editor of the first type;
an editor that is optimized for dealing efficiently with syntax is of the
second.
On Thu, Jun 02, 2011 at 04:18:35PM +0900, Xavier Noria wrote:
--
Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]
Chad I never said you don't know what you are talking about. I think you do know of course.
My thesis is that the Ruby editor in RubyMine undertands Ruby better than non-dedicated editors do. That's it, and I think that is just a fact.
I insist I am talking about the editor itself, not the integrated environment as a whole. As I said I use the editor and the console.
When I have a local variable unused, the editor warns me. I appreciate that. I appreciate a lot of the Ruby and Ruby on Rails knowledge builtin.
So in my cons and pros balance, it wins. In yours, Vim wins. That's totally fine!
Curious does RubyMine have a vi mode?
Though I mentioned that vim has plugins I personally don't use them.
In fact if Bostic's vi had syntax highlighting I would probably never
install vim.
I do find it interesting that so many IDE style features have been
reproduced in this terminal editor. There are many rails specific
projects for vim.
Though I have never used it there is even a tetris clone that teaches
you the key layout which may be an interesting tool to practice for
the autodidact who need another resource besides vimtutor.
~
On Thu, Jun 2, 2011 at 12:38 PM, Xavier Noria <fxn@hashref.com> wrote:
Chad I never said you don't know what you are talking about. I think you do know of course.
My thesis is that the Ruby editor in RubyMine undertands Ruby better than non-dedicated editors do. That's it, and I think that is just a fact.
I insist I am talking about the editor itself, not the integrated environment as a whole. As I said I use the editor and the console.
When I have a local variable unused, the editor warns me. I appreciate that. I appreciate a lot of the Ruby and Ruby on Rails knowledge builtin.
So in my cons and pros balance, it wins. In yours, Vim wins. That's totally fine!
There's this plugin
though I have not used it.
On Thu, Jun 2, 2011 at 8:40 PM, Stu <stu@rubyprogrammer.net> wrote:
Curious does RubyMine have a vi mode?
IdeaVIM is great. I use PyCharm daily at work, and RubyMine and
IntelliJ IDEA occasionally, and I always use IdeaVIM. I think you'd be
hard pressed to find a better vim plugin in an IDE.
On Jun 2, 1:00 pm, Xavier Noria <f...@hashref.com> wrote:
On Thu, Jun 2, 2011 at 8:40 PM, Stu <s...@rubyprogrammer.net> wrote:
> Curious does RubyMine have a vi mode?There's this plugin
though I have not used it.
