Re: Input line editing

[Johnny Billquist <bqt%softjar.se@localhost>]

der Mouse wrote:
> > And line editing is much less needed when you have all the nice
> > command completion in there.
>
> Maybe for typical TOPS-20 command lines.

True. TOPS-20 command lines don't come close to the complex mess a 
command line can be in Unix.

>  Definitely not so for me; I
> moderately routinely issue commands like
>
> % ( bzcat */log.bz2 ; cat curlog ) | awk 'NR==1 { base = $1; } { printf("%d %d 
> %s\n",$1-base,$7,substr($3,1,6)); }' | sort +1n | sed -e 's@\(.*\) \(.*\) \(.*\)@< 
> \3/log | sed -e '\''s/.*[[]//'\'' -e '\''s/[]].*//'\'' -e '\''s/.*/\2 & \1/'\'@ | sh | sort 
> | uniq -c | sort -n | tail

Wow. While not exactly TECO, you are almost getting close. :-)
Yes, that kind of stuff can't be handled by any completion. Line editing 
is nice, but it's kindof no real solution to that kind of headache. :-)

> I have some reason to think I'm unusual in this respect, but I daresay
> there are plenty of other ways completion doesn't make up for lack of
> real editing too.

Well, in Unix I'd agree. Since command line arguments can be programs 
for instance, which no completion ever can help you out much with.
Command lines in some other OSes are far less complex. Admittedly that 
sometimes means you can't do as much from the command line either, but 
I'm not totally convinced that's a real problem. :-)

But we're drifting off topic here, so I'll stop now. I agree with you 
that a common command line editing feature would be nice, though. But I 
don't know how I'd go about it in a Unix system. In a way, I suspect 
that the terminal driver might be the place to have it, but it would 
still be a mess to implement, I think.

        Johnny

--
Johnny Billquist                  || "I'm on a bus
                                  ||  on a psychedelic trip
email: bqt%softjar.se@localhost             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol