F
Forrest Chang
Hi All:
This is related to previous inquiry of which (x)emacs were going to
RubyConf (of which, it's really only clear to me that Jim Weirich is).
Anyways, I'd like to beef up (x)emacs support for ruby beyond what
is already there. I've gotten the vibe that there are a number of
good practices out there, and prior to writing new stuff from scratch,
I'd like to collect what's out there. Then I'd like to distill the
collected knowledge into a coherent whole, and implement some additional
functionality.
The resulting package should be
- easy to install
- easy to use
- easy to figure out (POLS)
- just plain wow
-- you know the sort of things attributed to ruby or the Mac.
As it is, you have a pretty good functional ruby mode out of the
box (at least w/xemacs if you have the programming modes), but to get
more, you have to figure out things (like how to enable speedbar
support, etc..), collect things (like the rubygarden wiki), tweak
(hack compile-mode for ruby). Typically non emacs sorts always feel
it isn't worth the effort to learn even if the features are great.
The ruby ide for emacs (RIFE?) should work like this: "download,
double click and now (x)emacs is the coolest Ruby ide around", and
hopefully be the killer app for bringing ruby coders to emacs
Aside from collecting/distilling existing elisp/scripts/etc and
putting a coherent front end to them, I was hoping to add on a bit of
functionality, a good number of it gui related. Some ideas:
- improve rrb (ruby refactoring browser) support in emacs
- I'd played with it and it's kind of cool, but I'd want to
change the interface. Like highlight region, rt click/or
emacs chord to extract method, give new name, voila!
- uml class diagrams from the code and vice versa
- I'd written a class browser stealing the the look from MS's
object browser for Perl, and was on the verge of using the
same internal represntation to create UML diagrams
- intellisense
- In the simple case, it should be too hard
foo = Foo.new
foo.<intellisense provides allowable methods>
- While way limited compared to the static languages, I figure
this could be pretty handy, how many times have you written:
ary = []
ary.<intellisense would be convenient here>
- In other cases, I figured I'd cheat and embed the type (if known)
in a comment
def foo( bar) # bar : Bar
bar.<intellisense>
- From looking at the screenshots, I think xrefractory presents
the options in the minibuffer and/or buffers, which is a typical
emacs-y way of doing it, and probably a good 1st shot implementation.
However, I sort of like the visual studio dropdown list where you type
'.' is pruning out the options as you type visual.
I seem to think to make it work, I'd want to have single co-process
running in the background (for decent performance, as opposed to rrb
invoking a ruby program each time invoked) to keep the state of the
code/classes current and provide information to (x)emacs as well as
handle gui stuff. I know folks have written things with bidirectional
commmunication with (x)emacs -- using Xemacs as the editor in Sun's
workshop debugger, is the most.
What I'd need:
To see what folks are doing. I figured that RubyConf would be a
good place to collect info, and nothing beats sitting over someone's
shoulder seeing how he does stuff. The next best thing would be for
folks to describe what they do and share the source code, mebbe even a
instructional video as made popular by Rails.
Then I'd need some of the more seasoneed elisp hackers to put up
with me asking all kinds of ridiculous. Countless times in the past,
I've wanted to make emacs extensions, but could not find out how to do
what I wanted to do. I know what it is, and how to do it, but I dunno
the hooks to emacs or the elisp required to do it. If only ruby wereo
(x)emacs' extension language - but still I'd need to know the hooks
into emacs.
Does this sound interesting to anyone?
Forrest
This is related to previous inquiry of which (x)emacs were going to
RubyConf (of which, it's really only clear to me that Jim Weirich is).
Anyways, I'd like to beef up (x)emacs support for ruby beyond what
is already there. I've gotten the vibe that there are a number of
good practices out there, and prior to writing new stuff from scratch,
I'd like to collect what's out there. Then I'd like to distill the
collected knowledge into a coherent whole, and implement some additional
functionality.
The resulting package should be
- easy to install
- easy to use
- easy to figure out (POLS)
- just plain wow
-- you know the sort of things attributed to ruby or the Mac.
As it is, you have a pretty good functional ruby mode out of the
box (at least w/xemacs if you have the programming modes), but to get
more, you have to figure out things (like how to enable speedbar
support, etc..), collect things (like the rubygarden wiki), tweak
(hack compile-mode for ruby). Typically non emacs sorts always feel
it isn't worth the effort to learn even if the features are great.
The ruby ide for emacs (RIFE?) should work like this: "download,
double click and now (x)emacs is the coolest Ruby ide around", and
hopefully be the killer app for bringing ruby coders to emacs
Aside from collecting/distilling existing elisp/scripts/etc and
putting a coherent front end to them, I was hoping to add on a bit of
functionality, a good number of it gui related. Some ideas:
- improve rrb (ruby refactoring browser) support in emacs
- I'd played with it and it's kind of cool, but I'd want to
change the interface. Like highlight region, rt click/or
emacs chord to extract method, give new name, voila!
- uml class diagrams from the code and vice versa
- I'd written a class browser stealing the the look from MS's
object browser for Perl, and was on the verge of using the
same internal represntation to create UML diagrams
- intellisense
- In the simple case, it should be too hard
foo = Foo.new
foo.<intellisense provides allowable methods>
- While way limited compared to the static languages, I figure
this could be pretty handy, how many times have you written:
ary = []
ary.<intellisense would be convenient here>
- In other cases, I figured I'd cheat and embed the type (if known)
in a comment
def foo( bar) # bar : Bar
bar.<intellisense>
- From looking at the screenshots, I think xrefractory presents
the options in the minibuffer and/or buffers, which is a typical
emacs-y way of doing it, and probably a good 1st shot implementation.
However, I sort of like the visual studio dropdown list where you type
'.' is pruning out the options as you type visual.
I seem to think to make it work, I'd want to have single co-process
running in the background (for decent performance, as opposed to rrb
invoking a ruby program each time invoked) to keep the state of the
code/classes current and provide information to (x)emacs as well as
handle gui stuff. I know folks have written things with bidirectional
commmunication with (x)emacs -- using Xemacs as the editor in Sun's
workshop debugger, is the most.
What I'd need:
To see what folks are doing. I figured that RubyConf would be a
good place to collect info, and nothing beats sitting over someone's
shoulder seeing how he does stuff. The next best thing would be for
folks to describe what they do and share the source code, mebbe even a
instructional video as made popular by Rails.
Then I'd need some of the more seasoneed elisp hackers to put up
with me asking all kinds of ridiculous. Countless times in the past,
I've wanted to make emacs extensions, but could not find out how to do
what I wanted to do. I know what it is, and how to do it, but I dunno
the hooks to emacs or the elisp required to do it. If only ruby wereo
(x)emacs' extension language - but still I'd need to know the hooks
into emacs.
Does this sound interesting to anyone?
Forrest