Ruby and IDE

[Ruben]

everytime the vim vs emacs thread comes up i like to make these two
points:


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

 

[Austin Ziegler]

FYI, the Java version of this construct would look something like,

public class SimpleTable {
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?

-austin

 

[David Holroyd]

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?

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

 

[Joe Van Dyk]

everytime the vim vs emacs thread comes up i like to make these two
points:


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...

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]

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.

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]

I've been long time user of emacs, but finally switched over to using
vim. That was my major problem with emacs. My wrists really hurt after
I started using my tiny laptop with small keyboard.

Kent.

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...

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?

 

[kyu]

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.

That's 1000000000000x better, thanks!

 

[Kent Sibilev]

You can do :shell, but currently it's impossible to switch between the
shell window and your buffers.

Kent.

 

[kyu]

everytime the vim vs emacs thread comes up i like to make these two
points:


and that's ALL you have to do to get a command line in emacs



ok, but this is scarier:



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

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
...

Rob
http://www.jedit.org/ruby/

 

[Kent Sibilev]

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.

 

[Rob .]

Kent, what I meant to say was:
"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
*Java* development. Perhaps some people will feel the same way if we
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.

 

[tsuraan]

Perhaps you mean something different, but wouldn't

!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]

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.

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...

I also use this windows manager called "ratpoison" which takes care of
multiple windows for me flawlessly.

 

[Austin Ziegler]

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.


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.


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
...

Rob
http://www.jedit.org/ruby/

 

[Austin Ziegler]

(Second try. Sorry about the first, folks.)

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.

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.

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

 

[Stefan Lang]

maybe you mean something like:
http://www.freehackers.org/kvim/vimpart.html

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]

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...

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.

 

[Ara.T.Howard]

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.

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
===============================================================================