>>>> [...mail(1)...editline...vi mode...] >> ps Mouse: no, this should not be in the kernel ... asking the kernel >> to search back and get text from something you entered 3 weeks (and >> several reboots) ago is just unreasonable.
That's (part of) why I said "as far as ordinary applications are concerned". As I said, I think it really should be in a user-specific userland program, one the user can switch out for a different one, much like the shell in that respect. However, designing the interfaces in question is...a bit of a challenge. I've been mulling it over for years and still have nothing but vague half-formed ideas. The hard part, of course, is that, while simple programs willbe happy with basic line editing, many others want different things beyond that. Many programs want to support various additional commands beyond whatever the user considers basics. And then there's the question of what to do when a user's idea of "basics" conflicts with what the program is trying to supply - witness, for example, my own struggles with bash on Linux and ^P. > I think Mouse refers to a thread on TUHS (where all the old hands of > UNIX are, and some idiots, too, [...]). Not specifically. I am not familiar with TUHS in a practical sense. I agree with the quote attributed to Rob Pike, but I was not aware of it when I wrote my previous mail. I think that input line editing, no matter how fancy, should be invisible to simple applications, as invisible as erase and kill processing is for applications that run in cooked mode today. Applications that want frills, such as shells that want input history that stretches back across multiple sessions, programs that want completion of their own private command names, those will have to do something to get them. But then, they do now too; it's just a question of designing the right interfaces. But even that much is no easy task. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
