Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!shadooby!samsung!uunet!garfield!stretch!jeff1 From: jeff1@garfield.mun.edu (Jeff Sparkes) Newsgroups: gnu.bash.bug Subject: Re: slight readline modification Message-ID: Date: 15 Nov 89 12:26:19 GMT References: <1989Nov14.063818.17288@fxgrp.fx.com> Sender: news@stretch.MUN.EDU Organization: Memorial University of Newfoundland Lines: 30 In-reply-to: grady@fxgrp.fx.com's message of 14 Nov 89 06:38:18 GMT >>>>> On 14 Nov 89 06:38:18 GMT, grady@fxgrp.fx.com (Steven Grady) said: grady> First thing I want to say is that I'm way impressed with the grady> input editing features of bash (ie the readline library). I'm grady> very appreciative of the work that went into making a good vi grady> mode, especially. And it even has multiple undo! Now, on to grady> the suggestions... Actually, multiple undos are a sort of side effect. Both multiple and vi style will be in my next bunch. I've even added undoable undos. grady> I currently use tcsh, and one thing it does that bash's grady> readline doesn't is put the cursor at the _end_ of the line grady> when you start moving through the history (in either vi or grady> emacs mode). Having the cursor at the end is slightly better grady> since you're more likely to be editing the arguments of an grady> input line, or adding a redirection, than changing the program grady> itself. (At least that's true with me.) Either method fits grady> within the editing paradigm (if you look at it as though the grady> cursor is at the end of the current (empty) line before you grady> start editing). Perhaps it can be configurable in the grady> .inputrc? Well, it's currently done the way that ksh does it, which is what *I* expect. Shouldn't be too hard to add a variable. It does have to go in the .inputrc, and not be yet another magic shell variable. -- Jeff Sparkes jeff1@garfield.mun.edu || uunet!garfield!jeff1 Humans couldn't have invented golf without alien intervention--Kids in the Hall