On Sat, Feb 19, 2022 at 1:45 PM Rob Pike <robpike(a)gmail.com> wrote: Lots of us would have loved to care about them and were sad that we couldn't until they were open sourced much later.

Terminal editing was done in general on the Blit and follow-on systems. That's primarily why the Research shells didn't do it. But history (ha!) chose another path. -rob On Sun, Feb 20, 2022 at 10:20 AM Sven Mascheck <mascheck(a)in-ulm.de> wrote:

On 2/19/22 6:11 PM, Sven Mascheck wrote: I think it's that the people with the power to make it happen didn't view it as an appropriate feature for the shell. It was much easier to implement in the shell, both technically and socially. Instead of having to convince kernel developers to implement and maintain editing in the terminal driver (both emacs and vi modes, to boot), it's easier for one person, maybe a few, to do a user-space implementation. That's how it ended up in ksh, for instance. Rob already talked about the Blit editing, which obviated the need to have it in the shell. Almquist released `atty' the same time as `ash', so he did at least provide a way to do editing and history using ptys, in the same way that `rlwrap' wraps readline. But he decried its lack of "elegance," and described it as something that "should be rewritten properly, with appropriate kernel support." Elegant, maybe, but it never seemed to take off. There were a few different implementations, but none was ever blessed as something officially integrated into a widely-distributed kernel. (As I recall, Jon Payne, who wrote JOVE while in high school (!), wrote one as a college course project. I remember him describing it on Usenet back in the day. There were others.) It always seemed like it would have been just the thing to implement as a tty streams module, but research Unix went in a different direction. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet(a)case.edu http://tiswww.cwru.edu/~chet/

On 2/20/22 4:02 PM, Larry McVoy wrote: History maybe, but most folks seem to want editing more, and just that incremental improvement would have made a difference. That's why readline is a library, with application-specific hooks available, and relies on something like rlwrap if you want to use editing and history with an unmodified application. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet(a)case.edu http://tiswww.cwru.edu/~chet/

On 2/20/22 4:19 PM, Lyndon Nerenberg (VE7TFX/VE6BBM) wrote: It's not that hard. The complexity is in how sophisticated you want to get with redisplay and whether you want to allow user-specified key bindings. There have been several implementations (I never did one). I suspect that the people who were in a position to integrate that functionality into distributed kernels were not supportive, or the code didn't get to them at the right time. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet(a)case.edu http://tiswww.cwru.edu/~chet/

On Sun, Feb 20, 2022 at 5:05 PM Dan Cross <crossd(a)gmail.com> wrote: Actually, isn't it usually better to put functionality in userspace libraries than inside an OS kernel, where feasible? Big kernels are buggier and less secure.

its a logistic supply curve. When it exceeds the available memory, and we've run out of PDP8 cores to recycle, they declare it's done and ship V1.0. If you can predict the asymptote, put your Roth on memory shares! On Tue, Feb 22, 2022 at 3:42 PM Rob Pike <robpike(a)gmail.com> wrote: