[ruby-talk:6366] Re: Thoughts on a Ruby browser

[e-mail] wrote:

> ...
> 1. Yes, we do have to have SOME kind of interface. But let's keep it
> as independent from the core functionality as we can.

I agree totally.  But this isn't a real problem for Ruby.  (A benefit of a
highly dynamic language!)

> 2. I do favor the possibility of a web-based browser. In fact, I
> wouldn't mind if it was *truly* web-based, i.e., you could look at
> code running on a remote machine as long as it had an embedded web
> server.

That might have it's points, but is probably not a really good idea.
Better would be a good interface with, say, Mozilla.  Ruby is really nice,
but it is slow when compared to good native compiled code.

> 3. I do also favor the possibilty of a "native" GUI, whether your
> desktop of choice is Win32 or Linux KDE. In a case like this, I
> would prefer an MDI interface, as nonmodal as possible.

This should also be kept separate from the core of Ruby.  Ruby should be
minimalizeable, as if for embedding.  The extensions should be managed via
libraries to the greatest extent possible.  That said, YES!!  What might be
looked at would be a wrapper around GTK.  Or, perhaps a wrapper around CLX
(Borland has just announced that CLX will be optionally GPL, and if this is
true on both Windows and Linux, then it !might! be a better choice).  And
of course there is TCL.

> 4. I'm not an emacs weenie, but numerous people I respect are. I
> favor a way to hook the browser into emacs (and whatever other
> editors are powerful enough).

Many people like emacs, but most descriptions that I've heard have been
discouraging.  Still, I see no reason why an IDE shouldn't allow people to
choose an alternate editor.

> 5. No matter the interface, I am a big believer in "collapse and
> hide" features. For example, when looking at code, I would like to
> be able to hide the embedded docs. I would like only a very shy,
> unobtrusive hint that the docs are even there. Yet on the other
> hand, I would like a feature that says, "Collect ALL the embedded
> docs and show them to me."

I would like to be able to view a single class or a single routine in
detail.  And also to spread it all out.  But perhaps this wouldn't be a
first round feature.

> ...
> 7. I want the browser to remember every detail of the state I was
> in at the end of my last session.

This can be nice, and shouldn't be hard.  But could easily be a second
iteration feature.

> 8. Possibly allow changing of syntax to equivalent forms by a simple
> keystroke combination or button click. (Hmm, I'll change that for-loop
> to a .each, and I'll change these braces to a do-end...) Does anyone
> remember the Alice Pascal compiler from long ago (1985)? In some ways
> it was very neat... it had a syntax-directed editor that made it nearly
> impossible to make a syntax error, and easy to make changes of the
> sort I just mentioned. Unfortunately, it also made it rather difficult
> to type in even a correct program...

Think carefully about this one.  This may be more complex than the gain
would justify.  Unless you can think of an easy way to write it?  (I'm just
getting started in Ruby, though I *do* have strong opinions about IDEs.)

> 9. I favor a flexible and customizable interface. Let me create my own
> macros (in Ruby, of course), assign icons to them, and add them to the
> toolbar.

Another good feature that should be a second round feature.  Remember KISS!

> 10. I'd like the capability to click on a standard identifier and get
> documentation on it -- different levels of documentation, beginning
> with just, for example, the "prototype" of a method. I'd like to click
> on the user-defined stuff and get information about it -- where is it
> first defined, where is it used, etc.

This might be a good choice for the first round, if it's easy enough to
do.  It could make learning the language much faster, and would be helpful
even later.

> 11. I wish (though this is not possible in Ruby as it is) that we could
> associate a comment specifically with the piece of code it belongs
> with. I have often thought that perhaps program text should advance to
> the point that it was more like a word-processing document, with a
> browser-like tool required in order to use it... that is a break with
> tradition, and millions would disagree with me, though.

Umnh... Possible?  Why not?   If we are creating an IDE, then we can expect
that there will be a project file.  The project file could hold this kind
of comment.  But remember to keep the program files separate from the extra
stuff.  Embedding this would be like embedding the colors used for syntax
highlighting.  Possible, but an idea that would make the compiler much more
complex.

> Just a few thoughts.
>
> Hal
>
> --
> Hal Fulton
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.

I think of an IDE as basically an index of what files are needed combined
with a syntax aware editor.  The editor is not necessarily perfectly syntax
aware, though irb demonstrates that this is not unreasonable for Ruby, so I
think that it should be perfectly syntax aware.  Really nice is if it does
keyword and special thing highlighting (special colors for strings,
comments, etc.)  Also nice is if it recognizes already defined terms
(perhaps not in the first round?).  It stores this info in a project file,
which is basically a directory of the files needed to build the project,
though other information can be stored there also.  And it should allow
test executions of the work in progress.  I don't really like it to
evaluate each line as it is typed.  Ruby Window is a much better example
(but it would be nice if it didn't lock up on program errors).

A GUI builder is a really nice feature in an IDE, but is sufficiently
complex that it probably isn't a good choice for inclusion in the first
iteration.  A later iteration should allow the GUI to be built, but perhaps
not allow the GUI to be rebuilt after the code has been modified.  How to
deal with that seems a more difficult topic best saved for later.



-- (c) Charles Hixson
--  Addition of advertisements or hyperlinks to products specifically
prohibited