[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

[ANN] Irb enhancements

Cs. Henk

3/9/2005 12:29:00 PM

Hi list!

I have some enhancements for irb:

* support for bash-style multiline editing (multiline commands are
stored in one history entry)

* context sensitive completion:

- within a string which is prefixed by "require", completion
lets you choose among ruby scripts (and c extensions) which can be
required, according to $:

- otherwise, if you are within a string, filename completion is
performed

- within backticks ("`") the first word is completed as an executable
in your ENV["PATH"]

- in other cases usual method/variable name completion is applied

... and some further nuances.

See a more detailed description in

http://www.creo.hu/~c...irb-enhancements/doc/files/R...

Check it out at

http://www.creo.hu/~c...

Csaba
13 Answers

Charles Mills

3/9/2005 5:40:00 PM

0


Cs. Henk wrote:
> Hi list!
>
> I have some enhancements for irb:
>
> * support for bash-style multiline editing (multiline commands are
> stored in one history entry)

been waiting for this!
>
> * context sensitive completion:
>
> - within a string which is prefixed by "require", completion
> lets you choose among ruby scripts (and c extensions) which can
be
> required, according to $:

very nice!
>
> - otherwise, if you are within a string, filename completion is
> performed
>
> - within backticks ("`") the first word is completed as an
executable
> in your ENV["PATH"]
>
> - in other cases usual method/variable name completion is applied
>
> .. and some further nuances.
>
> See a more detailed description in
>
> http://www.creo.hu/~c...irb-enhancements/doc/files/R...
>
> Check it out at
>
> http://www.creo.hu/~c...

These are all very useful features. Thanks for this!

-Charlie

Joel VanderWerf

3/9/2005 6:29:00 PM

0

Cs. Henk wrote:
> Hi list!
>
> I have some enhancements for irb:
>
> * support for bash-style multiline editing (multiline commands are
> stored in one history entry)

I've wanted this for a long time! (Stupid me, I thought zsh was the only
shell with multiline editing.)

> * context sensitive completion:

Looking forward to checking this out too.

Ben Giddings

3/9/2005 6:52:00 PM

0

Joel VanderWerf wrote:
>> * support for bash-style multiline editing (multiline commands are
>> stored in one history entry)
>
> I've wanted this for a long time! (Stupid me, I thought zsh was the only
> shell with multiline editing.)

Yay for zsh!

I agree, these ri enhancements are really cool. I thought I was the
only one who missed all the fancy zsh features when I dropped into IRB. :)

Ben

Cs. Henk

3/9/2005 9:42:00 PM

0

On Thu, Mar 10, 2005 at 03:28:47AM +0900, Joel VanderWerf wrote:
> >* support for bash-style multiline editing (multiline commands are
> >stored in one history entry)
>
> I've wanted this for a long time! (Stupid me, I thought zsh was the only
> shell with multiline editing.)

I wrote "bash style", which is not the same as "zsh style".

According to my classification, there are three type of multiline
editing models (actual keymaps are irrelevant as far as the
classification goes, of course):

* bash style: after entering a multiline command, the up arrow (or
ctrl-p) brings back the whole multiline command in one. Then it behaves
as one long line, you can move left and right within the line.

* zsh style: after entering a multiline command, the up arrow (or
ctrl-p) brings back the whole multiline command in one. Then it behaves
as an array of lines, up/down arrow moves between the lines, and
left/right arrow moves within a line. As I know, there is no way to go
back in one step from one multiline block to the other, you have to
climb up linewise. While in general it's better than bash style, this
latter behaviour could be quite painful after a ten line class
definition. Maybe not an issue for a shell, but is an issue for irb.

* pyrepl style: after entering a multiline command, ctrl-p
brings back the whole multiline command in one, Then it behaves as an
array of lines, up/down arrow moves between the lines, and left/right
arrow moves within a line. Hitting ctrl-p/ctrl-n always moves between
multiline blocks.

So the most advanced model is that of pyrepl. Tell me if I missed
something and these things are also possible in zsh (or bash).

By the way, if you don't know what pyrepl is: it's mwh's excellent
readline-a-like in python. Worth to check out, at least to play with
these features (but if I happen to do something with python, I can't
imagine that without pyrepl -- you can imagine, getting multiline
editing right is much more an issue with python than with everything
else). You find it at http://codespeak.n..., just unpack the
tarball, cd into the top dir, and type "python pythoni".

My idea is that pyrepl should be ported to ruby eventually. Not only it
has the mentioned features, but then we would have a totally accessible
and controllable access to readline functionality in pure ruby, and one
wouldn't need to meditate which other parts of readline should have a ruby
binding for being able to implement this idea or that.

Csaba

Ben Giddings

3/9/2005 10:44:00 PM

0

Cs. Henk wrote:
> * zsh style: after entering a multiline command, the up arrow (or
> ctrl-p) brings back the whole multiline command in one. Then it behaves
> as an array of lines, up/down arrow moves between the lines, and
> left/right arrow moves within a line. As I know, there is no way to go
> back in one step from one multiline block to the other, you have to
> climb up linewise. While in general it's better than bash style, this
> latter behaviour could be quite painful after a ten line class
> definition. Maybe not an issue for a shell, but is an issue for irb.
>
> * pyrepl style: after entering a multiline command, ctrl-p
> brings back the whole multiline command in one, Then it behaves as an
> array of lines, up/down arrow moves between the lines, and left/right
> arrow moves within a line. Hitting ctrl-p/ctrl-n always moves between
> multiline blocks.

In zsh up-arrow and ctrl-p are both bound (by default) to
'up-line-or-history'. If you're on any given line of a command and hit
"meta-x up-history" you'll go to the previous entry, not up lines.
Getting the pyrepl behaviour should be as simple as binding Ctrl-P to
up-history.

> My idea is that pyrepl should be ported to ruby eventually. Not only it
> has the mentioned features, but then we would have a totally accessible
> and controllable access to readline functionality in pure ruby, and one
> wouldn't need to meditate which other parts of readline should have a ruby
> binding for being able to implement this idea or that.

Wasn't someone looking at rewriting readline so that we could have a non
GPLed readline implemenation for Ruby? In addition to the licensing
issue, this would sure make lives easier for OS X users.

Ben

Sam Roberts

3/9/2005 11:22:00 PM

0

Quoting bg-rubytalk@infofiend.com, on Thu, Mar 10, 2005 at 07:44:25AM +0900:
> Wasn't someone looking at rewriting readline so that we could have a non
> GPLed readline implemenation for Ruby? In addition to the licensing
> issue, this would sure make lives easier for OS X users.

There are BSD-licenced readlines around, with GNU readline compatible
APIs, even.

Cheers,
Sam

Cs. Henk

3/9/2005 11:30:00 PM

0

On Thu, Mar 10, 2005 at 07:44:25AM +0900, Ben Giddings wrote:
> In zsh up-arrow and ctrl-p are both bound (by default) to
> 'up-line-or-history'. If you're on any given line of a command and hit
> "meta-x up-history" you'll go to the previous entry, not up lines.
> Getting the pyrepl behaviour should be as simple as binding Ctrl-P to
> up-history.

Ah, thanks! That's interesting.

However, there are more to pyrepl's line editing than this. If I
remember correctly, I could instert lines in the middle of a previously
typed code block. Quite annoying, I just couldn't get this behaviour
now. Maybe I have the wrong memories?

> >My idea is that pyrepl should be ported to ruby eventually. Not only it
> >has the mentioned features, but then we would have a totally accessible
> >and controllable access to readline functionality in pure ruby, and one
> >wouldn't need to meditate which other parts of readline should have a ruby
> >binding for being able to implement this idea or that.
>
> Wasn't someone looking at rewriting readline so that we could have a non
> GPLed readline implemenation for Ruby? In addition to the licensing
> issue, this would sure make lives easier for OS X users.

It's interesting. Is there any pointer to this? GPL, non-GPL, pyrepl
port, doing it from scratch: either case what would make sense then
would be doing it in pure ruby...

Btw, one of the reasons for creating pyrepl was to get readline features
under a non-GPL license. It's liberal license is an entry in the feature
list :)

Csaba

Sam Roberts

3/10/2005 12:46:00 AM

0

Quoting csaba-ml@beastie.creo.hu, on Thu, Mar 10, 2005 at 08:29:54AM +0900:
> > Wasn't someone looking at rewriting readline so that we could have a non
> > GPLed readline implemenation for Ruby? In addition to the licensing
> > issue, this would sure make lives easier for OS X users.
>
> It's interesting. Is there any pointer to this? GPL, non-GPL, pyrepl
> port, doing it from scratch: either case what would make sense then
> would be doing it in pure ruby...

FYI - a readline-like library I used with the rc shell, worked well, to
my knowledge:

http://vons.free...

License:

Vrl is copyright (C)1996-2000 by Gert-Jan Vons <gert-jan@bigfoot.com>.
You can re-use this code if you want, as long as you give me credit.


Cheers,
Sam

Cs. Henk

3/10/2005 2:04:00 AM

0

On Thu, Mar 10, 2005 at 09:45:50AM +0900, Sam Roberts wrote:
> Quoting csaba-ml@beastie.creo.hu, on Thu, Mar 10, 2005 at 08:29:54AM +0900:
> > > Wasn't someone looking at rewriting readline so that we could have a non
> > > GPLed readline implemenation for Ruby? In addition to the licensing
> > > issue, this would sure make lives easier for OS X users.
> >
> > It's interesting. Is there any pointer to this? GPL, non-GPL, pyrepl
> > port, doing it from scratch: either case what would make sense then
> > would be doing it in pure ruby...
>
> FYI - a readline-like library I used with the rc shell, worked well, to
> my knowledge:
>
> http://vons.free...

Certainly it's good to hear of such things -- I knew only of libedit as
an alternative for readline --, it's just what's the ruby in it? When
you told, "Wasn't someone looking at rewriting readline so that we could
have a non GPLed readline implemenation for Ruby?", you meant that
someone writes an alternative of readline and then it's left to the ruby
community to wrap it? I tought someone does work on something directly
for ruby...

Btw, I heard of attempts of using libedit with ruby instead of readline.
I don't have the link right here, but it's easy to find it in Google's
group search on comp.lang.ruby. Someone had a patchset for this, but the
link to that was dead. Maybe that could be found with some more effort.

Csaba

Martin DeMello

3/10/2005 7:24:00 AM

0

Cs. Henk <csaba-ml@beastie.creo.hu> wrote:
> Hi list!
>
> I have some enhancements for irb:
>
> * support for bash-style multiline editing (multiline commands are
> stored in one history entry)

Wonderful!

martin