From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,HTML_MESSAGE,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 26803 invoked from network); 3 Jan 2023 16:55:30 -0000 Received: from minnie.tuhs.org (50.116.15.146) by inbox.vuxu.org with ESMTPUTF8; 3 Jan 2023 16:55:30 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 17EFA424F9; Wed, 4 Jan 2023 02:55:06 +1000 (AEST) Received: from mail-oi1-f171.google.com (mail-oi1-f171.google.com [209.85.167.171]) by minnie.tuhs.org (Postfix) with ESMTPS id 683C3424F6 for ; Wed, 4 Jan 2023 02:55:01 +1000 (AEST) Received: by mail-oi1-f171.google.com with SMTP id u204so27069650oib.7 for ; Tue, 03 Jan 2023 08:55:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=pBe9sJu6CWLkzU6gXHUAs2RtXfE8vBshkVhfkXpjgRw=; b=JXB3hUv9OJfaK35ktC5QsAq4W9Y18BXFCAgQOkoZbu706FX+9M30mZAkRClqH67DfC 5GypaLJ+r2a2rfmzG90YvyqpUYKdEqyDCrit5wYgEb1ekIG7K96NJ3KIs6ZlLHBEyRYK Ng4j+oFgn526ezdFr7LZYReuCxjlnTOqE0Am09tP21EGMns5NAV2FwYAt3IavSAZACcX hxLChiWVMupY06trMY0KplNrAuXNhF98NcJZYCms7iwFQ4LyEc22OXysXaiVagXHGcff EtoROKem2oHO4dpSG+/EA96RV+J4jkqmGTPnfAjfddv7ZR0JiuBBGCfPyN6jmfdIGFfi 4Fsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=pBe9sJu6CWLkzU6gXHUAs2RtXfE8vBshkVhfkXpjgRw=; b=S9eQZrviVsH0psrutyca30qyOI/KrgJVg7QjxyYveKpyjp0abYYKDZbtWdu9wccDqI CTvcF96XhB0WKMGE//3J1nNo6efUIpz5GKMVunvigcLdnj155RLKICiAv1YdeCSZJbGW jtaORo3O4HvITkREpxsIOpBVhlN2lKCtHNZpIaMjkTRkXWPd2CtpfKM9buKEGkbZvJ3t kRV51Owtsh+ZiNMDWFI6W6G1mpT7tnAHcTI4impvesVEXGSogNsL1HVva+FFAI+TLya7 +yH6rfkWJSfo4/krpHeM879J5q2IOPcCWNWpmG7A+BBwODLOH+ssfGzrbW3NWQ2qXdwH 8Hdg== X-Gm-Message-State: AFqh2kqIUdXckaibqagdbG+odpxI6zTG51Cjrnq540IzIiFZudXZDnlJ +LAn/4hUzi7Eytb8Zd1kH+kDu0c9GX6U7LmksWiTzrg7ecY= X-Google-Smtp-Source: AMrXdXujFh9U8uEydoIHvJ2HaSxps7g93KVCKTjpt4PiE3EkxK4PmnXAWsFfXM67ZpmGleQfxyZbcJfw198WROduS0g= X-Received: by 2002:a05:6808:8f2:b0:35c:25a0:291b with SMTP id d18-20020a05680808f200b0035c25a0291bmr1675394oic.135.1672764840664; Tue, 03 Jan 2023 08:54:00 -0800 (PST) MIME-Version: 1.0 References: <52FB6638-AEFF-4A4F-8C2E-32089D577BA0@planet.nl> <464819f0-d2f6-2a60-6481-a194f4428b4d@case.edu> <20221230200246.GW5825@mcvoy.com> <8ca17d52-a25a-dbbf-e1f0-d743b8884cfa@in-ulm.de> In-Reply-To: From: Marshall Conover Date: Tue, 3 Jan 2023 11:53:49 -0500 Message-ID: To: Joseph Holsten Content-Type: multipart/alternative; boundary="0000000000001ee45905f15eeab0" Message-ID-Hash: MRWARTOHF5ES6TRVEMXMBPW4FE2OSGBI X-Message-ID-Hash: MRWARTOHF5ES6TRVEMXMBPW4FE2OSGBI X-MailFrom: marzhall.o@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tuhs.tuhs.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: Tautological Eunuch Horticultural Scythians X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [TUHS] Re: Command Line Editing in the Terminal Driver (Was: A few comments on porting the Bourne shell) List-Id: The Unix Heritage Society mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --0000000000001ee45905f15eeab0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Along these lines but not quite, Jupyter Notebooks have stood out to me as another approach to this concept, with behavior I'd like to see implemented in a shell. With these notebooks, users type text into blocks, and then can have these blocks evaluated by some underlying engine, with the results of the evaluation showing up in a block underneath where they entered text. Results can be not only text, but things like rendered charts and images. There may be GUI-interactable rendered elements as well, but I'm unsure. Notably, text-entry blocks are created such that each new block holds onto the context of the previous blocks. So, a variable defined in the first eval block will be available in later blocks. Currently these are used primarily for demonstrating APIs, exploring data with python, or writing quick PoCs that can then be extracted into an application. Some companies, such as Netflix, have experimented with using them entirely as a replacement for shell scripts, which is the sort of research I'd most love to see. Fundamentally, I think it's a smell that the way we interact with our systems is tied to the long-gone hardware requirement of "be usable with a teletype." Acme was certainly a move towards recognizing the value of being able to reuse space that, in TTYs, would be 'dead' text. The ability to evaluate commands in Acme, and the further inclusion of an underlying evaluator that holds state by Jupyter were good steps forward, I think. I'd love to see experimentation with a whole system that takes the jupyter approach, with nested namespaces forming applications, combined with data being held in "blocks" as well as code - much like acme opens and edits files as well as letting you execute either them or snippets in them. I think there's a chance something could be developed that would better fit the way we interface with computers today, and the underlying engine approach would move us toward the "everything speaks one language" design we lost in the move from shells to standalone GUI applications. Mostly, I'd be bummed to see yet another shell that pretends it's behind a "glass teletype", to use the tongue-in-cheek term from "Ed Mastery", or just continuing elaboration on that design, despite the fact I use shells daily. It's the best we have now, but I feel like it's the way forward. Cheers! Marshall P.S. - Kakoune is neat and I'm going to have to poke around at that, thanks for pointing it out. On Mon, Jan 2, 2023 at 3:03 PM Joseph Holsten wrote: > On Fri, Dec 30, 2022, at 12:42, Sven Mascheck wrote: > > and in "ksh - An Extensible High Level Language" David Korn writes: > > - "Originally the idea of adding command line editing to ksh was > rejected in the hope that line editing would move into the terminal > driver." [2] > > [2] https://www.in-ulm.de/~mascheck/bourne/korn.html > > > This phrase has haunted me for years. It=E2=80=99s so clearly the =E2=80= =9Ccorrect=E2=80=9D > separation of concerns, until you actually attempt implementing it. And > Bourne=E2=80=99s irregular grammar certainly doesn=E2=80=99t help here. I= =E2=80=99d prefer to move > beyond readline, ideally something like text objects per > vim/zsh/treesitter. But having one parser in the interpreter and another = in > the line editor becomes quite exciting if you want a true bourne or even > posix sh. > > But the thing that brought be back to playing against this quote again > this year was starting to research the QED lineage and discovering helix = & > kakoune. Honestly, they feels like the most coherent advancements in > QED-style editors since sam & acme. (Yes, I=E2=80=99m irrationally exclud= ing vim > text-objects, mostly because no one removed editor features that t-o made > redundant. It=E2=80=99s as if ed had twice as many commands, one for rege= xp matches > and one for pre-ken-QEDist exact matches.) > > Anyway, the only time I=E2=80=99ve really seen =E2=80=9Cline editing [=E2= =80=A6] move into the > terminal driver=E2=80=9D sound possible was acme=E2=80=99s win. For those= who haven=E2=80=99t had > the pleasure, rsc describes it at 15:25 in https://research.swtch.com/acm= e. > =E2=80=9CI worked for many years in a shell without history or command li= ne > editing, and I never missed it because Acme is providing this for me.=E2= =80=9D > > It=E2=80=99s hard to convey how surprisingly pleasant sh or rc can be wit= hin acme > win to someone who has only used them within a mere > terminal-emulator-emulator. Especially since a greenfield terminal app > has more code emulating old xterm behaviors than physical vt100 behaviour= s. > This is especially exhausting when you try to use something like NeoVim= =E2=80=99s > :term expecting it to just work and discover that buffer-line-wrapping on > window-resize hasn=E2=80=99t been implemented. > > Anyone seen any other =E2=80=9Cterminal drivers=E2=80=9D that provide a p= leasant > alternative to line editing? > -- > ~j > --0000000000001ee45905f15eeab0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Along these lines but not quite, Jupyter Notebooks ha= ve stood out=20 to me as another approach to this concept, with behavior I'd like to se= e implemented in a shell.

With these notebooks,=20 users type text into blocks, and then can have these blocks evaluated by some underlying engine, with the results of the evaluation showing up=20 in a block underneath where they entered text. Results can be not only text= , but things like rendered charts and images. There may be GUI-interactable= rendered elements as well, but I'm unsure.

Notably, text-entry blocks are created such that each new block holds onto the=20 context of the previous blocks. So, a variable defined in the first eval block will be available in later blocks.

Currentl= y these are used primarily for demonstrating APIs, exploring data with=20 python, or writing quick PoCs that can then be extracted into an=20 application. Some companies, such as Netflix, have experimented with=20 using them entirely as a replacement for shell scripts, which is the=20 sort of research I'd most love to see.

Fundame= ntally, I think it's a smell that the way we interact with our systems is tied= to the long-gone hardware requirement of "be usable with a teletype.&= quot;=C2=A0 Acme was certainly a move towards recognizing the value of being able to reuse space that, in TTYs, would be= 'dead' text. The=20 ability to evaluate commands in Acme, and the further inclusion of an under= lying evaluator that holds state by Jupyter were good steps forward, I thin= k.

I'd love to see experimentation with a whol= e system that takes the jupyter approach, with nested namespaces forming ap= plications, combined with data being held in "blocks" as well as= code - much like acme opens and edits files as well as letting you execute= either them or snippets in them. I think there's a chance something co= uld be developed that would better fit the way we interface with computers = today, and the underlying engine approach would move us toward the "ev= erything speaks one language" design we lost in the move from shells t= o standalone GUI applications.

Mostly, I'= d be bummed to see yet another shell that pretends it's behind a "= glass teletype", to use the tongue-in-cheek term from "Ed Mastery= ", or just continuing elaboration on that design, despite the fact I u= se shells daily. It's the best we have now, but I feel like it's th= e way forward.

Cheers!

Ma= rshall

P.S. - Kakoune is neat and I'm going to have t= o poke around at that, thanks for pointing it out.

On Mon, Jan 2, = 2023 at 3:03 PM Joseph Holsten <joseph@josephholsten.com> wrote:
On Fri,= Dec 30, 2022, at 12:42, Sven Mascheck wrote:

and in "ksh - An Extensible High Level La= nguage" David Korn writes:

  • =C2=A0"Originally the idea of addi= ng command line editing to ksh was rejected in the hope that line editing would move into the terminal driver." [2]
This phrase has haunted me for years. It=E2=80=99s so clearly = the =E2=80=9Ccorrect=E2=80=9D separation of concerns, until you actually at= tempt implementing it. And Bourne=E2=80=99s irregular grammar certainly doe= sn=E2=80=99t help here. I=E2=80=99d prefer to move beyond readline, ideally= something like text objects per vim/zsh/treesitter. But having one parser = in the interpreter and another in the line editor becomes quite exciting if= you want a true bourne or even posix sh.

But = the thing that brought be back to playing against this quote again this yea= r was starting to research the QED lineage and discovering helix & kako= une. Honestly, they feels like the most coherent advancements in QED-style = editors since sam & acme. (Yes, I=E2=80=99m irrationally excluding vim = text-objects, mostly because no one removed editor features that t-o made r= edundant. It=E2=80=99s as if ed had twice as many commands, one for regexp = matches and one for pre-ken-QEDist exact matches.)

=
Anyway, the only time I=E2=80=99ve really seen =E2=80=9Cline editing [= =E2=80=A6] move into the terminal driver=E2=80=9D sound possible was acme= =E2=80=99s win. For those who haven=E2=80=99t had the pleasure, rsc describ= es it at 15:25 in=C2=A0https://research.swtch.com/acme. =E2=80=9CI worked for many= years in a shell without history or command line editing, and I never miss= ed it because Acme is providing this for me.=E2=80=9D

It=E2=80=99s hard to convey how surprisingly pleasant sh or rc can = be within acme win to someone who has only used them within a mere terminal= -emulator-emulator. Especially since a greenfield terminal app has mo= re code emulating old xterm behaviors than physical vt100 behaviours. This = is especially exhausting when you try to use something like NeoVim=E2=80=99= s :term expecting it to just work and discover that buffer-line-wrapping on= window-resize hasn=E2=80=99t been implemented.

Anyone seen any other =E2=80=9Cterminal drivers=E2=80=9D tha= t provide a pleasant alternative to line editing?
--
~j
--0000000000001ee45905f15eeab0--