Ruby IDE

Ruby
21

Besides that, in general I find myself slowed down constantly hitting
Ctrl-[, forgetting whether I’m in command mode or not. Either that, or
I’m filling my files with “:w” or “>>” or “i”, “b”, “w”…

The Ctrl-[ thing is interesting to me, because I’ve never heard of
anyone else escaping that way. Out of curiosity, is your control key
in the corner of your keyboard, or next to the ‘a’ key? For me, with
my control key right by my ‘a’ key, hitting ctrl-[ is really quick and
easy. The escape key is just too far off the home row for me to bother
with :slight_smile:

22

On 4/25/06, Logan C. [email protected] wrote:

–VISUAL–
Right. Maybe I just haven’t gotten into the habit of glancing down at
the bottom of the window. It seems to me to take less concentration to
just hit Ctrl-[ than to quickly look down and lose/find my place on
the page.

I find ESC to be much faster than Ctrl-[, YMMV.

I use a funky programmable keyboard which only has a tiny rubber Esc
button up away from the main keys. (
Kinesis Advantage2 Ergonomic Keyboard | Kinesis Keyboards and Mice ). So Ctrl-[ turns out to be
faster for me.

23

I found that I never use the caps lock key, so I remapped it to be
another
Esc. Works great for vim. Until you use another computer…

Mark

24

On 4/26/06, [email protected] [email protected] wrote:

Besides that, in general I find myself slowed down constantly hitting
Ctrl-[, forgetting whether I’m in command mode or not. Either that, or
I’m filling my files with “:w” or “>>” or “i”, “b”, “w”…

The Ctrl-[ thing is interesting to me, because I’ve never heard of
anyone else escaping that way. Out of curiosity, is your control key
in the corner of your keyboard, or next to the ‘a’ key? For me, with
my control key right by my ‘a’ key, hitting ctrl-[ is really quick and
easy. The escape key is just too far off the home row for me to bother
with :slight_smile:

On the Contoured keyboard (see link in my previous post), you hit the
control keys (and alt keys, and a few others) with your thumbs. It’s
symmetrical, so you can use either thumb.

The escape key is way up to the top left side of the keyboard and is
just a little rubber nub of a key, about 6 mm X 9 mm, and is not
useful for regular use. You have to take your left hand off the home
row to reach it (and hope you hit it instead of one of the also tiny
rubber F-keys).

Incidentally, I type using the dvorak layout, and on my keyboard the
‘[’ is in a fairly awkward position (2 rows down from the home row on
my right ring finger), but is still way easier to deal with than the
Esc key.

25

Hmm. The only thing that turned me off to Emacs was the
weird command names–and probably the lisp-ness, had I
gotten close enough to it to get into that.

Which gets me thinking…

Ruby is Lisp-like…Emacs is based on Lisp…
There really ought to be an editor based on Ruby…

…it could start with new user interface semantics
that adhere to the standards that have evolved
over the last 35 years

…that would make it easy to use right from the start

…it could use Ruby, and be extended with Ruby, so
it could be customized and evolved using the
rather terrific language that Ruby is

So much to code, so little time…
:_)

26

[fixed top-posting]

On 4/29/06, Eric A. [email protected] wrote:

try the demos of the commercial editors, try Eclipse FreeRIDE and the

Which gets me thinking…

Ruby is Lisp-like…Emacs is based on Lisp…
There really ought to be an editor based on Ruby…

I believe FreeRIDE is written in Ruby, as are the plug-ins you might
write for it.

So much to code, so little time…
:_)

Again – I think more good things should be happening with FreeRIDE in
the near future, especially after the wxRuby rewrite is done (and
there’s been good progress on that front lately).

27

Eric A. wrote:

Ruby is Lisp-like…Emacs is based on Lisp…
There really ought to be an editor based on Ruby…

…it could start with new user interface semantics
that adhere to the standards that have evolved
over the last 35 years

…that would make it easy to use right from the start

…it could use Ruby, and be extended with Ruby, so
it could be customized and evolved using the
rather terrific language that Ruby is

Hm. There are editors that can be scripted and extended in Ruby. As
someone else mentioned, FreeRIDE. But I hear/see that vi(m) can also be
driven by Ruby. Diakonos is still young and fledgling, but it is almost
fully scriptable in Ruby; that is, if you can press a key to do a
certain function, then you can also call that function in a Ruby script.

Pistos

28

SleepJunk13 wrote:

Is there a standard IDE out there that most people use? I’m looking at
Mondrian and Arachno now, but I’m not sure which. I’m also looking at
FreeRIDE as well, but I don’t know.

Well, there’s no right answer to this. Everyone has a different coding
style, workflow style, and personality, so everyone fits best with a
different editor.

The two standard editors amongst professional Unix programmers are Emacs
and vi. There has been something of an ongoing tongue in cheek holy war
between their adherents for twenty-some years now. (See
Editor war - Wikipedia , which also lists some
advantages of each.) Both are open source, completely free (both libre
and gratis) and now also available as precompiled binaries for Windows,
Mac, and most other platforms.

I (and many other people) swear by Emacs. There are two main forks,
XEmacs (http://www.xemacs.org/) and GNU Emacs
(GNU Emacs - GNU Project). Emacs is extremely powerful - it
is actually a LISP interpreter with a whole lot of predefined LISP code
to make it work as a text editor. There are file browsers, editing modes
with syntax highlighting, autoindent, autocomplete, etc. for most
programming languages, including Ruby, and there are optional Emacs LISP
addons available for just about anything a computer can do. (Really.
Almost everything. Web browsers, mail readers, http servers, Tetris, AI
chat programs…) The flipside is that the learning curve is not
particularly shallow, but there are good tutorials and lots and lots of
documentation available. I do have friends who are just as passionate
and productive with vi, though (and they love to point out that vi
doesn’t immediately take up 35 megs of memory when you start it.)

I have tried various other commercial, shareware, and free IDEs and
editors over the years, and I have never found any feature that they
have that Emacs doesn’t do. On the other hand, I always find lots of
things that Emacs can do that they don’t do. I always keep coming back
to Emacs :slight_smile:

If you’re serious about programming, I recommend you take some time to
try them all. Try Emacs for a few days, try vi or vim for a few days,
try the demos of the commercial editors, try Eclipse FreeRIDE and the
other free IDEs… It’s really a matter of personal choice and taste
more than anything else, and trying a bunch of editors yourself is the
only way to figure out which one suits you best.

Best,
Paul

–

– Paul L., Senior Software Engineer –
— Networked Knowledge Systems —
---- P.O. Box 20772 Tampa, FL. 33622-0772 ----
----- (813)594-0064 Voice (813)594-0045 FAX -----
------ [email protected] ------

29

On May 4, 2006, at 1:20 AM, John G. wrote:

main .rb file for the editor, and one conf file. Sadly, aside from a
few comments here and there in the code and in the conf file, Diakonos
looks to be entirely undocumented.

There is a readme describing how to install (which is (happily)
trivial), but no mention anywhere how to use the editor (though,
passing “–help” (I guessed that one) gives 4 lines of info). I also
guessed that Ctrl-q exits the editor, but that’s it.

The site implies that its first release was in June, 2004.

The config file is pretty easy on the eyes, you can pick up the
keybindings from that.

30

On 5/3/06, Pistos C. [email protected] wrote:

[snip] Diakonos is still young and fledgling, but it is almost
fully scriptable in Ruby; that is, if you can press a key to do a
certain function, then you can also call that function in a Ruby script.

Pistos

I just had a brief look at Diakonos. Seems nice and clean: just one
main .rb file for the editor, and one conf file. Sadly, aside from a
few comments here and there in the code and in the conf file, Diakonos
looks to be entirely undocumented.

There is a readme describing how to install (which is (happily)
trivial), but no mention anywhere how to use the editor (though,
passing “–help” (I guessed that one) gives 4 lines of info). I also
guessed that Ctrl-q exits the editor, but that’s it.

The site implies that its first release was in June, 2004.

31

First, thanks to John for pointing out that FreeRide
is most likely exactly the thing I’m using for.

Next, Pistos:

After many years coding, I became a writer. But I
still code whenever I can. But the result of the
writing experience led me to start writing the user
guide as part of the design process.

Note for aqile developers:
The user guide is one of process artifacts at
every stage. You modify it at the start of each
cycle to explain what you plan to have accomplished
at the end of the cycle. If the plan changes, you
modify the document accordingly.

That experience had several tremendous benefits:

  • When I finally finished coding a project, I was
    generally too burned out to write a user guide.

  • Since a project was never really “finished”, it
    was hard to define that point at which I really
    /should/ write the guide.

  • When I was coding, a myriad of ideas would occur
    to me about things the users ought to know. When
    I wrote at the end of a project, I always had the
    nagging feeling that I was only recalling a fraction
    of the things I wanted to say.

  • But with the user guide already written, it’s an
    easy matter to add such things as they come in
    note format to be fleshed out later, if in no other
    form.

I’ve used that strategy successfully on several projects.
The user guide lets people give me feedback on how they
want to work even before it’s written. And you never
find yourself in that awful position where you’ve created
something great, but no one uses it because they can’t
find out how.

I’ll do a design document as well, to keep track of
implementation ideas. Between the two of them, I’ve
never needed a “specification”.

32

Fascinating. I’m familiar with plugins for writing
major extensions. But what about writing small macros?

Is there a “macro” capability in FreeRide, or are
plugins the new-world way of customizing behaviors?

-------- Original Message --------
From: John G. [email protected]
Reply-To: [email protected]

On 4/29/06, Eric A. [email protected] wrote:

Hmm. The only thing that turned me off to Emacs was the
weird command names–and probably the lisp-ness, had I
gotten close enough to it to get into that.

Which gets me thinking…

Ruby is Lisp-like…Emacs is based on Lisp…
There really ought to be an editor based on Ruby…

I believe FreeRIDE is written in Ruby, as are the plug-ins
you might write for it.

…it could start with new user interface semantics
that adhere to the standards that have evolved
over the last 35 years

…that would make it easy to use right from the start

…it could use Ruby, and be extended with Ruby, so
it could be customized and evolved using the
rather terrific language that Ruby is

Again – I think more good things should be happening with
FreeRIDE in the near future, especially after the wxRuby
rewrite is done (and there’s been good progress on that
front lately).

33

John G. wrote:

I just had a brief look at Diakonos. Seems nice and clean: just one
main .rb file for the editor, and one conf file. Sadly, aside from a
few comments here and there in the code and in the conf file, Diakonos
looks to be entirely undocumented.

There is a readme describing how to install (which is (happily)
trivial), but no mention anywhere how to use the editor (though,
passing “–help” (I guessed that one) gives 4 lines of info). I also
guessed that Ctrl-q exits the editor, but that’s it.

You are absolutely correct: There is very little user documentation. I
actually have more solid plans to come up with more material (online
documentation, in-application help) to give a better out-of-box
experience within the next two releases. I’ve walked a few people
through getting started, but I completely agree that a quick start
walkthrough of some kind is definitely in order. That and sprucing up
the F1 page by, perhaps, organizing into groups and showing the most
commonly used keybindings higher up.

I’ve also entertained notions of making a “for people coming from emacs”
conf file which would override most keystrokes to match emacs.

Thanks for trying Diakonos.

Pistos

34

Similar, but with an important difference. The user
guide tells someone how to use the program to do what
they need to do. It’s necessarily use-case oriented.

Comments tend to be implementation-oriented. They
tell how the /program/ does what it does. The user
guide tells the /user/ how to do what they need to do.

35

Eric A. wrote:

Note for aqile developers:
The user guide is one of process artifacts at
every stage. You modify it at the start of each
cycle to explain what you plan to have accomplished
at the end of the cycle. If the plan changes, you
modify the document accordingly.

Similar to what I call “comment-driven development”

–
James B.

?Design depends largely on constraints.?
? Charles Eames

36

Eric A. wrote:

Similar, but with an important difference. The user
guide tells someone how to use the program to do what
they need to do. It’s necessarily use-case oriented.

Comments tend to be implementation-oriented. They
tell how the /program/ does what it does.

Well, comments that just describe what the code is doing aren’t always
helpful. I tend toward comments that explain the purpose and rationale
for the code. The code itself should be clear enough to describe what
it is doing.

Yes, they are always user-centric. But they do often have a “thinking
out loud” quality which is handy when writing up user docs.

The comments are often user stories that are then transmogrified into
tests and code to make the stories live.

–
James B.

“In Ruby, no one cares who your parents were, all they care
about is if you know what you are talking about.”

  • Logan C.
37

Eric A. wrote:

Next, Pistos:
After many years coding, I became a writer. But I
still code whenever I can. But the result of the
writing experience led me to start writing the user
guide as part of the design process.

  • Since a project was never really “finished”, it
    was hard to define that point at which I really
    /should/ write the guide.
  • When I was coding, a myriad of ideas would occur
    to me about things the users ought to know. When
    I wrote at the end of a project, I always had the
    nagging feeling that I was only recalling a fraction
    of the things I wanted to say.
    I’ve used that strategy successfully on several projects.
    The user guide lets people give me feedback on how they
    want to work even before it’s written. And you never
    find yourself in that awful position where you’ve created
    something great, but no one uses it because they can’t
    find out how.

Interesting points; thanks for sharing. I’ve absorbed them, and will
change the development process of Diakonos a bit.

I’ve recently released 0.8.1, and with it, I’ve begun growing a Diakonos
wiki: http://wiki.purepistos.net/doku.php?id=Diakonos At the moment,
there is a Getting Started page, as well as a larval “Tips and Tricks”
section which describes some perhaps unobvious features of Diakonos.

I still would like to follow through on the claim/goal that Diakonos is
(will be) a “usable” editor. Part of that is making the learning curve
shallow and the first-impression Ruby-like.

Pistos

38

Ah ha. VERY nice. I see the integration now.

39

Cool! I look forward to finding out more.

40

We are currently developing an IDE (“Ruby In Steel”) for Visual Studio
2005.

The current release (0.5) has
Code colouring
Code collapsing
Integrated interactive console
Commenting/uncommenting
Bracket matching/location
Project Manager (tree view pane)
Syntax errors - click to find

The next release (0.6) due out in about 2 weeks has:
Debugging
Breakpoints
drag/drop watch variables
step into/step over
autos window
locals window
call stack
interactive debug console

After that we are adding Rails support features, IntelliSense, snippets
etc.

You can keep up to date with developments at:
http://www.sapphiresteel.com/

best wishes
Huw