From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,RCVD_IN_VALIDITY_RPBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.4 Received: from txout-a4-smtp.messagingengine.com (txout-a4-smtp.messagingengine.com [103.168.172.227]) by inbox.vuxu.org (Postfix) with ESMTP id C18A63126F for ; Tue, 13 May 2025 16:22:47 +0200 (CEST) Received: from localhost.localdomain (kubehost04.phl.internal [10.202.3.4]) by mailtxout.phl.internal (Postfix) with ESMTP id C454023801BD for ; Tue, 13 May 2025 10:22:46 -0400 (EDT) ARC-Authentication-Results: i=3; topicbox.com; arc=fail (as.1.mailchannels.net=pass, ams.1.mailchannels.net=fail (body has been altered)) smtp.remote-ip=23.83.222.63; dkim=pass (2048-bit rsa key sha256) header.d=ecloud.org header.i=@ecloud.org header.b=jhRRz2jB header.a=rsa-sha256 header.s=dreamhost x-bits=2048; dmarc=none policy.published-domain-policy=none policy.applied-disposition=none policy.evaluated-disposition=none (p=none,d=none,d.eval=none) policy.policy-from=p header.from=ecloud.org; spf=pass smtp.mailfrom=lists@ecloud.org smtp.helo=frog.ash.relay.mailchannels.net; x-internal-arc=fail (as.2.topicbox.com=fail (message has been altered), ams.2.topicbox.com=fail (body has been altered), as.1.mailchannels.net=pass, ams.1.mailchannels.net=fail (message has been altered)) ARC-Message-Signature: i=3; a=rsa-sha256; c=relaxed/relaxed; d= topicbox.com; h=from:content-type:mime-version:subject:date :references:to:in-reply-to:message-id:list-help:list-id :list-post:list-subscribe:reply-to:content-transfer-encoding :list-unsubscribe; s=sysmsg-1; t=1747146166; bh=kpD6bwPysCb9rCCc ZdXGaf1UW7Yl3tpK/XJI9shGq0g=; b=fUxhAuboXrJv04JFASb9AJZudJP+bb9o xw3Tk18z6MdI1/sJ8xRr6LtATWGkR//h0DRgTWvWu8AJYani+QSng+0pWvYb2ZRU FuuRhaGHajvLtvT/kraEJx6LwIvz3lfnJWN77vjqMgYHzUHWDSyOtfHOJJOI2dkX Uf40IqB5vCA= ARC-Seal: i=3; a=rsa-sha256; cv=fail; d=topicbox.com; s=sysmsg-1; t= 1747146166; b=NHwzt6Kjv4kwEcPbeCtnI/pW1aQUV8uf3TBjxjKYtpTw/yBQtE JCu/Fyob5EZmZAmEmURmfojK6omcbfcauJZBdrZUTXiQy4W7RNVCuVeVXn4CEpZt XidHkfOIbCZTe/lKRV3DNu/kliGsRl1Oj/mSlBtQMTfKyau19T/dUUsus= Authentication-Results: topicbox.com; arc=fail (as.1.mailchannels.net=pass, ams.1.mailchannels.net=fail (body has been altered)) smtp.remote-ip=23.83.222.63; dkim=pass (2048-bit rsa key sha256) header.d=ecloud.org header.i=@ecloud.org header.b=jhRRz2jB header.a=rsa-sha256 header.s=dreamhost x-bits=2048; dmarc=none policy.published-domain-policy=none policy.applied-disposition=none policy.evaluated-disposition=none (p=none,d=none,d.eval=none) policy.policy-from=p header.from=ecloud.org; spf=pass smtp.mailfrom=lists@ecloud.org smtp.helo=frog.ash.relay.mailchannels.net; x-internal-arc=fail (as.2.topicbox.com=fail (message has been altered), ams.2.topicbox.com=fail (body has been altered), as.1.mailchannels.net=pass, ams.1.mailchannels.net=fail (message has been altered)) X-Received-Authentication-Results: mx.topicbox.com; arc=fail (as.1.mailchannels.net=pass, ams.1.mailchannels.net=fail (body has been altered)) smtp.remote-ip=23.83.222.63; bimi=skipped (DMARC did not pass); dkim=pass (2048-bit rsa key sha256) header.d=ecloud.org header.i=@ecloud.org header.b=jhRRz2jB header.a=rsa-sha256 header.s=dreamhost x-bits=2048; dmarc=none policy.published-domain-policy=none policy.applied-disposition=none policy.evaluated-disposition=none (p=none,d=none,d.eval=none) policy.policy-from=p header.from=ecloud.org; iprev=pass smtp.remote-ip=23.83.222.63 (frog.ash.relay.mailchannels.net); spf=pass smtp.mailfrom=lists@ecloud.org smtp.helo=frog.ash.relay.mailchannels.net; x-aligned-from=pass (Address match); x-me-sender=none; x-ptr=pass smtp.helo=frog.ash.relay.mailchannels.net policy.ptr=frog.ash.relay.mailchannels.net; x-return-mx=pass header.domain=ecloud.org policy.is_org=yes (MX Records found: mx2.mailchannels.net,mx1.mailchannels.net); x-return-mx=pass smtp.domain=ecloud.org policy.is_org=yes (MX Records found: mx1.mailchannels.net,mx2.mailchannels.net); x-tls=pass smtp.version=TLSv1.3 smtp.cipher=TLS_AES_256_GCM_SHA384 smtp.bits=256/256; x-vs=clean score=0 state=0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=9fans.net; h=from :content-type:mime-version:subject:date:references:to :in-reply-to:message-id:list-help:list-id:list-post :list-subscribe:reply-to:content-transfer-encoding :list-unsubscribe; s=dkim-1; t=1747146166; x=1747232566; bh=Vz0s f98scH7d02P+TOAa6lJGSZyx3jcha0x4NCJ7lKc=; b=qTuZsRH+W1BOzkQozCmf N1HNs+9sgU6hDG22lWO7bwn2oeYfDO9gOchfrjFj6y13OS6r48kM6gabgPb/CMba Htb6ijbb78kQPs41J0QoUromP82jvRjxA9SHftQaNESDQdNoWzILaf6mGJ+r7Z/K JuPwoxzVnXxC8vUbVbM/FLQ= Received: from mx.topicbox.com (10-0-1-36.authmilter.topicbox-prod.svc.cluster.local [10.0.1.36]) by tb-mx-3.topicbox.com (Postfix) with ESMTP id 4776B10017FD2B6A for <9fans@9fans.net>; Tue, 13 May 2025 14:15:44 +0000 (UTC) Received: from tb-mx-1.topicbox.com (10.0.0.54 [10.0.0.54]) by mx.topicbox.com (Authentication Milter) with ESMTP id 3C718282C88; Tue, 13 May 2025 14:15:44 +0000 ARC-Seal: i=2; a=rsa-sha256; cv=fail; d=topicbox.com; s=arcseal; t= 1747145744; b=Yk7D1n0S/jrDG4T2OmrkB2BvO0sJIokz+7dYw/XzknWzizSAyR BG9FPPxQMD2tPEsE9WSk77kXthy21ev18gMyEE/6nK5w5US11uzRi8MP5qCkvtaY uL+AGc0i7HmGjL63FtSNwHI7Ps88X5FfG7K9G5hKEvCBnnHczEecsHBjbDqQ6eb1 /2tPV16kZZQjo9+zisQQQ4RGiLwlNZbIxLubJLGpf/kDidUq61B3Pc4Rg+ACWWu8 mfWmpKcARns2lRdNVwz/Tienc+0Et4XY2tbUJFYkSTs8OiiahFcyUn1kHp/b7IX+ m1zvW7g+hAvQk2xrHXYe4XnzqKvnp24gNSmA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d= topicbox.com; h=from:content-type:mime-version:subject:date :references:to:in-reply-to:message-id; s=arcseal; t=1747145744; bh=2g0/lVw32ICocYl2j1Am2jfARBU1CEVC3Byq6JvpU7w=; b=JT6AuOOMZt9x h2JVhmVHSiz189bdESsU5uIVMYvDtXs+4hN4vEYhy5ogc469iwUcmj99OSEpfkno CyVCkis99UoigmP4/7LBs7MlgLKzW+7DQL9Ypocn97dhRbcMF4VVK5/yXlTIaUFe dfEubMNxDofolJ9kpVZPZjUlV2+bJkQIJ3vAJltY1RhFfYTca1XWM5wPP307ZWyv uLJhfKT1kDCO2r8+nr35H11KLe7beFcEiJuL8d/4GC5GdgFHFzNToDyVi+tdmWrh hK6kkYFwkyyRvyRksD6dYb1DVw8W9nUguvLQp7+/a1DU9Q0xvH8bHZFrA3D50CQe Cfboidk4rA== ARC-Authentication-Results: i=2; mx.topicbox.com; arc=fail (as.1.mailchannels.net=pass, ams.1.mailchannels.net=fail (body has been altered)) smtp.remote-ip=23.83.222.63; bimi=skipped (DMARC did not pass); dkim=pass (2048-bit rsa key sha256) header.d=ecloud.org header.i=@ecloud.org header.b=jhRRz2jB header.a=rsa-sha256 header.s=dreamhost x-bits=2048; dmarc=none policy.published-domain-policy=none policy.applied-disposition=none policy.evaluated-disposition=none (p=none,d=none,d.eval=none) policy.policy-from=p header.from=ecloud.org; iprev=pass smtp.remote-ip=23.83.222.63 (frog.ash.relay.mailchannels.net); spf=pass smtp.mailfrom=lists@ecloud.org smtp.helo=frog.ash.relay.mailchannels.net; x-aligned-from=pass (Address match); x-me-sender=none; x-ptr=pass smtp.helo=frog.ash.relay.mailchannels.net policy.ptr=frog.ash.relay.mailchannels.net; x-return-mx=pass header.domain=ecloud.org policy.is_org=yes (MX Records found: mx2.mailchannels.net,mx1.mailchannels.net); x-return-mx=pass smtp.domain=ecloud.org policy.is_org=yes (MX Records found: mx1.mailchannels.net,mx2.mailchannels.net); x-tls=pass smtp.version=TLSv1.3 smtp.cipher=TLS_AES_256_GCM_SHA384 smtp.bits=256/256; x-vs=clean score=0 state=0 X-ME-VSCause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgdeftdegfeefucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggv pdfurfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucenucfjughrpefhtg gguffffhfvjgfkofesrgdtmherhhdtjeenucfhrhhomhepufhhrgifnhcutfhuthhlvggu ghgvuceolhhishhtshesvggtlhhouhgurdhorhhgqeenucggtffrrghtthgvrhhnpedule efhffhtdevledtjeelveelheduhfejteffgeehtedtvdegudfgteetvdehieenucffohhm rghinheprghrtggrnhdqfhgvrdgtohhmnecukfhppedvfedrkeefrddvvddvrdeifedpud ekhedrheehrddutdeirdehgeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhep ihhnvghtpedvfedrkeefrddvvddvrdeifedphhgvlhhopehfrhhoghdrrghshhdrrhgvlh grhidrmhgrihhltghhrghnnhgvlhhsrdhnvghtpdhmrghilhhfrhhomhepoehlihhsthhs segvtghlohhuugdrohhrgheqpdhnsggprhgtphhtthhopedupdhrtghpthhtohepoeelfh grnhhsseelfhgrnhhsrdhnvghtqe X-ME-VSScore: 0 X-ME-VSCategory: clean Received-SPF: pass (ecloud.org: Sender is authorized to use 'lists@ecloud.org' in 'mfrom' identity (mechanism 'include:netblocks.dreamhost.com' matched)) receiver=mx.topicbox.com; identity=mailfrom; envelope-from="lists@ecloud.org"; helo=frog.ash.relay.mailchannels.net; client-ip=23.83.222.63 Received: from frog.ash.relay.mailchannels.net (frog.ash.relay.mailchannels.net [23.83.222.63]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by tb-mx-1.topicbox.com (Postfix) with ESMTPS for <9fans@9fans.net>; Tue, 13 May 2025 14:15:42 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|lists@ecloud.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 309262400F for <9fans@9fans.net>; Tue, 13 May 2025 14:15:41 +0000 (UTC) Received: from pdx1-sub0-mail-a240.dreamhost.com (100-119-5-190.trex-nlb.outbound.svc.cluster.local [100.119.5.190]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 3B7BE24AE9 for <9fans@9fans.net>; Tue, 13 May 2025 14:15:39 +0000 (UTC) ARC-Seal: i=1; s=arc-2022; d=mailchannels.net; t=1747145740; a=rsa-sha256; cv=none; b=4pPb975fcgaTJfuDx5AOifLFZz9XrSyb/vQomSrksFdXRxa+EnJNBVwvJHFG1UYznLJyVL kVr4VZFc1j3f1gIBLHUilX1WvxrHxYuDqYuyTyKzKQejK0Xw3/7m9mDeV4srSFCzRyLXfG yOZvISA13HVxLBtl7+eV/8p3PLKDOah9M/1t01aQQCgTT6ajj170O6KO64E12GUvadlGQ4 5WZ/NidD95J+J9YKdwMkN4pYey942iVHJNXovlzCAaGmao/maUtfCQt5bWduKODQer7nv0 tCNmB8De4ZIhfi1Z3Peyelu4bO4q9lBZhrz8gxjgfjzgYvP5FtQ+Qk8ReoM3ZA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mailchannels.net; s=arc-2022; t=1747145740; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references:dkim-signature; bh=cUpGEmoI6Y6PY+RpXvR/DVyN4o/39g9OAERARo5DMM8=; b=rFYmvyS62AqDa1ykdsY3S7mINpXRY8cFv9NpfamHR9xx4Dh7zBTs0mEGdv/gcJivkagCgi 8B/AezuF3UAHLuLen3qKNWHVA6gAENCSuBVkhUl/heBvbF2WeVi946upPmMJw7rsgc7yNP LKdaV90tuEP0gjeLoGGxFXlD2lS7FYFJvzQ9EsVUc2qB6laCi5CQhUmy6xAo0fcS960wtS UJC8C4MD+LXRO9RqQnHjGhayxn5EU04nC8BTM8m+e2M5qt3da/hh7NP//4LOIubRJcCYbz cJxmXNGdut7Yozilh7ADan4C77BN217O83juReSGuOGqs4YYsri29R4l8YcX3Q== ARC-Authentication-Results: i=1; rspamd-57f676fcfb-8jqgv; auth=pass smtp.auth=dreamhost smtp.mailfrom=lists@ecloud.org X-Sender-Id: dreamhost|x-authsender|lists@ecloud.org X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|lists@ecloud.org X-MailChannels-Auth-Id: dreamhost X-Illegal-Reaction: 0b1f8391249d2fe6_1747145741026_702099369 X-MC-Loop-Signature: 1747145741026:2064241940 X-MC-Ingress-Time: 1747145741026 Received: from pdx1-sub0-mail-a240.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384) by 100.119.5.190 (trex/7.0.3); Tue, 13 May 2025 14:15:41 +0000 Received: from smtpclient.apple (unknown [185.55.106.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: lists@ecloud.org) by pdx1-sub0-mail-a240.dreamhost.com (Postfix) with ESMTPSA id 4ZxdmT57YHz9p for <9fans@9fans.net>; Tue, 13 May 2025 07:15:37 -0700 (PDT) From: Shawn Rutledge Content-Type: multipart/alternative; boundary="Apple-Mail=_CBD42059-3161-4F6B-B7D1-7554932DA9DD" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.500.181.1.5\)) Subject: Re: [9fans] Next Generation Acme Date: Tue, 13 May 2025 16:15:25 +0200 References: To: 9fans <9fans@9fans.net> In-Reply-To: Message-Id: <2F438B31-DD12-486E-A574-C9B5F3D8188F@ecloud.org> X-Mailer: Apple Mail (2.3826.500.181.1.5) Topicbox-Policy-Reasoning: moderate: sender is a member; group holds all messages Topicbox-Message-UUID: c34f4504-3004-11f0-870c-99edbf69fdda Archived-At: =?UTF-8?B?PGh0dHBzOi8vOWZhbnMudG9waWNib3guY29tL2dyb3Vwcy85?= =?UTF-8?B?ZmFucy9UNGYxYTIwOThiMWUxYzg1NC1NZDNjOWQwZmUyMTEzMjQxZDUxYWM0?= =?UTF-8?B?ZGRiPg==?= List-Help: List-Id: "9fans" <9fans.9fans.net> List-Post: List-Software: Topicbox v0 List-Subscribe: Precedence: list Reply-To: 9fans <9fans@9fans.net> Content-Transfer-Encoding: 7bit List-Unsubscribe: , Topicbox-Delivery-ID: 2:9fans:437d30aa-c441-11e9-8a57-d036212d11b0:522be890-2105-11eb-b15e-8d699134e1fa:Md3c9d0fe2113241d51ac4ddb:1:6d8mkwgR74hkLtalki9rXzgwnM8uGGbr_wnNQ5k6nkE --Apple-Mail=_CBD42059-3161-4F6B-B7D1-7554932DA9DD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 > On May 13, 2025, at 14:20, Aram H=C4=83v=C4=83rneanu wrot= e: >=20 > 5. Add enough ANSI terminal sequences support to win(1) such that > workarounds are no longer necessary for common CLI software (git(1), > grep(2), etc). ... > 13. Some sort of minimal markup support. Perhaps with colors. Not > arbitrary colors, just four or five predetermined colors that > Acme programs could make use of (for example I'd like to see colors > in my diffs). This should be done by a third party process writing > in acme(4), acme(1) should not implement native markdown support > or anything like that. It seems to be a core design principle that /dev/text is _only_ text. This= purism has been espoused in other contexts: for example the Arcan author i= s another who apparently doesn=E2=80=99t like that writing a terminal requi= res a complex state machine which is apt to have bugs: https://arcan-fe.com= /2017/07/12/the-dawn-of-a-new-command-line-interface/ (and other such artic= les). There=E2=80=99s some quote I remember seeing somewhere about every U= nix terminal (and even Linux itself, since the kernel started out as a term= inal emulator) having an ASR-33 at its heart: such an anachronism, such an = ad-hoc standard from the electromechanical days, surely we could do better = if we started from scratch. But you know, where do you draw the line: even = a space character has an effect on alignment of the next character, and we = don=E2=80=99t call it evil. A line feed moves the cursor too! What about = a tab? What about a vertical tab then? What is FF good for nowadays? If = we don=E2=80=99t like using most of the control codes, why are we wasting s= o much space at the beginning of the ASCII table with them? But at least a= control code is only one byte... Could we use them better for just a few = more cases, without having to write a state machine for multi-byte escape s= equences? But if we start using a few for styling or defining text spans, = maybe pretty soon it=E2=80=99s not enough codes anymore. A core idea that comes out of the Xanadu project is that assuming you can r= eliably make references to spans of text, in spite of text getting edited o= ver time (changes that you want to track actually), then you can use those = links for everything: for two-way hyperlinks stored separately, for transcl= usions, and perhaps even for tagging text spans with styles. The set of li= nks is then a bit like a fully-normalized database schema: assume that some= records already exist, and make a new table just to link the keys in one t= able to the keys of another. But being able to make unchanging references = to changing text is a tall order. So I would like to apply this principle to that: /dev/text should stay as i= t is, and we need a way to apply styling to spans of text within the window= . So we need a way to define the start and the end of the span, in spite o= f any editing that occurs. (There would be some edge cases, just as in any= word processor: if you put the cursor at the beginning or end of a styled = span and start typing, does it get the span's styling applied or not? You = can argue about which way is more correct; but this does not stop anyone fr= om writing word processors that deal with it one way or another.) If you i= nsert a newline somewhere in the window, maybe all the spans referring to l= ines below that will need updating, or can we be more clever than that some= how? I=E2=80=99ve been prototyping an application that works that way: I have a = device that serves up a 9p filesystem that contains (among other things) a = plain text file and a separate spans file, and I modified tail to use draw = to render colored text spans rather than just outputting the text itself. = (And then developed a more complex client program that renders some applica= tion-specific widgets around the colored text.) I think what I=E2=80=99m d= oing should work, but it=E2=80=99s buggy in practice: tail normally has to = read character-by-character backwards from the end of the file to find the = line breaks, and now my version has to further assume that the last span at= the end of the spans file applies to that last line that was found (thus d= efining the line number for that line even though we have not counted all t= he lines in the whole file), and stay in sync (iterating backwards and then= forwards again) from there on, even as both files change. (My device actu= ally stores the text in something like a ring buffer, but I=E2=80=99m tryin= g to preserve the illusion that the text and spans both keep growing indefi= nitely, forward from where it was at the time that a particular client open= s both files.) So maybe that difficulty illustrates why people like to mix = formatting into their text in such a myriad of ways (terminal codes, HTML, = markdown or whatever): either way you are doing multiplexing, but the more = explicitly the spans are mapped to the text, the more robust it will be. F= WIW I will be at iwp9 and can probably do a demo if it still works well eno= ugh at that time. What I would like to do next is modify rio=E2=80=99s window to have a /dev/= text.meta/spans file alongside /dev/text, and be able to write to the spans= file in case some non-default formatting is desired. Probably each span w= ill just specify a numeric semantic, and then I=E2=80=99ll have a lookup ta= ble in another file to map those numbers to specific fonts and colors (so s= tyling is modifiable dynamically). And each time you go back and modify hi= story, your edits will have a different semantic automatically (and thus ap= pear in a different color). So that=E2=80=99s for color and font support. But one experiment I was als= o thinking of trying with what we have already: if all you want is full con= trol of one screen-full of text, can you open /dev/text, get the file offse= t at that time, write your first screen-full, and then each time you update= you can just seek back to that offset and overwrite it with the next scree= n-full, or even make incremental modifications? I didn=E2=80=99t try it ye= t=E2=80=A6 but maybe monochrome curses-like UIs are possible that way? May= be I should try to write a top that way, unless somebody already did it. I wondered if acme supports graphics (using draw) like the underlying windo= w does: no, it does not, but I suspect that was something that could have e= ventually happened. I also wondered how easy it is to make splitters with sub-windows of text (= each with a tagline field at the top) like acme does, in my own program. I= t seems that=E2=80=99s quite a bit of work too: it=E2=80=99s not all librar= y code. Probably we could make it easier. I wanted sub-windows in this to= y application that I=E2=80=99m writing though, so I cheated and used Nuklea= r for now.=20=20 > 8. Add support for space-based indentation. Disgusting, but necessary > (I patched my acme to support this, but it still requires manual > activation, should be automatic). What kind of changes? > 14. Elastic tab support, or some better way of dealing with tabular > data. Yes! But I think that code belongs in the window, not acme. I want to be = able to pipe tab-separated tables to the terminal anytime and have them lin= ed up. Typewriters made better use of the tab key than most terminals do (= except you had to set up the tab stops in advance: you shouldn=E2=80=99t ha= ve to do that on a computer). It should become so commonplace that even ls= -l can use tabs to line up columns, and if you cat a source file, of cours= e you get indentation looking the same as it does in an editor (if it doesn= =E2=80=99t already). And I think adding this feature is probably easy comp= ared to the text-spans stuff I was describing above. > 16. No settings, no options, no themes, no syntax highlighting, no > keyboard based interface (the mouse is king). I wouldn=E2=80=99t break the mouse usage, but actually I want to use the ke= yboard more. Sorry. ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T4f1a2098b1e1c854-Md3c9d= 0fe2113241d51ac4ddb Delivery options: https://9fans.topicbox.com/groups/9fans/subscription --Apple-Mail=_CBD42059-3161-4F6B-B7D1-7554932DA9DD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8
On May 13, 2025, at 14:20, Aram Hăvărnea= nu <aram.h@mgk.ro> wrote:

5. Add enough ANSI ter= minal sequences support to win(1) such that
workarounds are no longer = necessary for common CLI software (git(1),
grep(2), etc).
<= /div>
...
13. Some sor= t of minimal markup support. Perhaps with colors. Not
arbitrary colors= , just four or five predetermined colors that
Acme programs could make= use of (for example I'd like to see colors
in my diffs). This sho= uld be done by a third party process writing
in acme(4), acme(1) shoul= d not implement native markdown support
or anything like that.

It seems to be a core design princip= le that /dev/text is _only_ text.  This purism has been espoused in ot= her contexts: for example the Arcan author is another who apparently doesn&= rsquo;t like that writing a terminal requires a complex state machine which= is apt to have bugs: https://arcan-fe.com/2017/07/12/the-d= awn-of-a-new-command-line-interface/ (and other such articles). &n= bsp;There’s some quote I remember seeing somewhere about every Unix t= erminal (and even Linux itself, since the kernel started out as a terminal = emulator) having an ASR-33 at its heart: such an anachronism, such an ad-ho= c standard from the electromechanical days, surely we could do better if we= started from scratch. But you know, where do you draw the line: even a spa= ce character has an effect on alignment of the next character, and we don&r= squo;t call it evil.  A line feed moves the cursor too!  What abo= ut a tab?  What about a vertical tab then?  What is FF good for n= owadays?  If we don’t like using most of the control codes, why = are we wasting so much space at the beginning of the ASCII table with them?=  But at least a control code is only one byte...  Could we use t= hem better for just a few more cases, without having to write a state machi= ne for multi-byte escape sequences?  But if we start using a few for s= tyling or defining text spans, maybe pretty soon it’s not enough code= s anymore.

A core idea that comes out of the Xan= adu project is that assuming you can reliably make references to spa= ns of text, in spite of text getting edited over time (changes that you wan= t to track actually), then you can use those links for everything: f= or two-way hyperlinks stored separately, for transclusions, and perhaps eve= n for tagging text spans with styles.  The set of links is then a bit = like a fully-normalized database schema: assume that some records already e= xist, and make a new table just to link the keys in one table to the keys o= f another.  But being able to make unchanging references to changing t= ext is a tall order.

So I would like to apply th= is principle to that: /dev/text should stay as it is, and we need a way to = apply styling to spans of text within the window.  So we need a way to= define the start and the end of the span, in spite of any editing that occ= urs.  (There would be some edge cases, just as in any word processor: = if you put the cursor at the beginning or end of a styled span and start ty= ping, does it get the span's styling applied or not?  You can argu= e about which way is more correct; but this does not stop anyone from writi= ng word processors that deal with it one way or another.)  If you inse= rt a newline somewhere in the window, maybe all the spans referring to line= s below that will need updating, or can we be more clever than that somehow= ?

I’ve been prototyping an application tha= t works that way: I have a device that serves up a 9p filesystem that conta= ins (among other things) a plain text file and a separate spans file, and I= modified tail to use draw to render colored text spans rather than just outputtin= g the text itself.  (And then developed a more complex client program = that renders some application-specific widgets around the colored text.) &n= bsp;I think what I’m doing should work, but it’s buggy in pract= ice: tail normally has to read character-= by-character backwards from the end of the file to find the line breaks, an= d now my version has to further assume that the last span at the end of the= spans file applies to that last line that was found (thus defining the lin= e number for that line even though we have not counted all the lines in the= whole file), and stay in sync (iterating backwards and then forwards again= ) from there on, even as both files change.  (My device actually store= s the text in something like a ring buffer, but I’m trying to preserv= e the illusion that the text and spans both keep growing indefinitely, forw= ard from where it was at the time that a particular client opens both files= .) So maybe that difficulty illustrates why people like to mix formatting i= nto their text in such a myriad of ways (terminal codes, HTML, markdown or = whatever): either way you are doing multiplexing, but the more explicitly t= he spans are mapped to the text, the more robust it will be.  FWIW I w= ill be at iwp9 and can probably do a demo if it still works well enough at = that time.

What I would like to do next is modif= y rio’s window to have a /dev/text.meta/spans file alongside /dev/tex= t, and be able to write to the spans file in case some non-default formatti= ng is desired.  Probably each span will just specify a numeric semanti= c, and then I’ll have a lookup table in another file to map those num= bers to specific fonts and colors (so styling is modifiable dynamically). &= nbsp;And each time you go back and modify history, your edits will have a d= ifferent semantic automatically (and thus appear in a different color).

So that’s for color and font support.  B= ut one experiment I was also thinking of trying with what we have already: = if all you want is full control of one screen-full of text, can you open /d= ev/text, get the file offset at that time, write your first screen-full, an= d then each time you update you can just seek back to that offset and overw= rite it with the next screen-full, or even make incremental modifications? =  I didn’t try it yet… but maybe monochrome curses-like UI= s are possible that way?  Maybe I should try to write a top that way, unless somebody already did it.

I wondered if acme supports graphics (using draw) like th= e underlying window does: no, it does not, but I suspect that was something= that could have eventually happened.

I also won= dered how easy it is to make splitters with sub-windows of text (each with = a tagline field at the top) like acme does, in my own program.  It see= ms that’s quite a bit of work too: it’s not all library code. &= nbsp;Probably we could make it easier.  I wanted sub-windows in this t= oy application that I’m writing though, so I cheated and used Nuklear= for now.  

8. Add supp= ort for space-based indentation. Disgusting, but necessary
(I patched = my acme to support this, but it still requires manual
activation, shou= ld be automatic).

What = kind of changes?

= 14. Elastic tab support, or some better way of dealing with tabular
da= ta.

Yes!  But I think t= hat code belongs in the window, not acme.  I want to be able to pipe t= ab-separated tables to the terminal anytime and have them lined up.  T= ypewriters made better use of the tab key than most terminals do (except yo= u had to set up the tab stops in advance: you shouldn’t have to do th= at on a computer).  It should become so commonplace that even ls -l can use tabs to line up columns, and if you= cat a source file, of course you get ind= entation looking the same as it does in an editor (if it doesn’t alre= ady).  And I think adding this feature is probably easy compared to th= e text-spans stuff I was describing above.

16. No settings, no options, no themes, no syntax highl= ighting, no
keyboard based interface (the mouse is king).
<= /div>

I wouldn’t break the mouse us= age, but actually I want to use the keyboard more.  Sorry.
<= br />
= --Apple-Mail=_CBD42059-3161-4F6B-B7D1-7554932DA9DD--