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.2 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED
	autolearn=no autolearn_force=no version=3.4.4
Received: (qmail 26179 invoked from network); 10 Aug 2023 14:14:35 -0000
Received: from 9front.inri.net (168.235.81.73)
  by inbox.vuxu.org with ESMTPUTF8; 10 Aug 2023 14:14:35 -0000
Received: from wopr.sciops.net ([216.126.196.60]) by 9front; Thu Aug 10 10:13:10 -0400 2023
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sciops.net; s=20210706;
	t=1691676760;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:  in-reply-to:in-reply-to;
	bh=aUBPc+z3bTRvL+pfmEQoTmjAoopBKtowwgmDFEatf4M=;
	b=lmloTgVtFaDm2/qHfhZwkkTnUrHSiQ1zln41fYjoq5O1OXivocj47mx354MkELBv98AR58
	dBwtqbjH7kFhW54qnjL9tY9PE+ntnps6MGugkDXqTvGz8fjnU8FMkSXBvV93m/IVQ6dP1G
	3pkXG9DVUGmGO/ff8LDRqosei7FLYQ8=
Received: 
	by wopr.sciops.net (OpenSMTPD) with ESMTPSA id d1848846 (TLSv1.2:ECDHE-RSA-CHACHA20-POLY1305:256:NO)
	for <9front@9front.org>;
	Thu, 10 Aug 2023 07:12:40 -0700 (PDT)
Message-ID: <F1515E9FDF229DBFBD09AC231B810FCF@wopr.sciops.net>
Date: Thu, 10 Aug 2023 16:13:04 +0200
From: qwx@sciops.net
To: 9front@9front.org
In-Reply-To: <CABB-WO8yV41n5S_ao4SfmWDBS-dqUN_zfJP0A1ZO3MWEzH2dhw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
List-ID: <9front.9front.org>
List-Help: <http://lists.9front.org>
X-Glyph: ➈
X-Bullshit: anonymous replication GPU optimizer 
Subject: Re: [9front] "Touching the Artwork" strikes again
Reply-To: 9front@9front.org
Precedence: bulk

> The discussion should have been should it be enabled at all.
> 
> I'm pretty against keyboard control in window management in
> particular, triply so on Plan 9, but keybindings could actually be
> tolerated if they were available only while the window management menu
> is quasimodally held open with button 3. It's better than the nested
> GNU Screen way of controlling where commands go.
> 
> And Exit is neither really "window management" anyway nor something
> anyone is actually missing if it's undiscoverable without a man page
> read.
> 
> And q to quit is a Plan 9 standard already.
> 
> Also, if checking for /env/wsys is too much magic (this was the real
> reason Exit was enabled - not that anyone actually *uses* it in the
> parent rio) you could check for service=cpu instead and get
> practically the same result.

The current state was generally agreed upon after plenty of
discussion, which occurred before, during and after the patches
surrounding rio Exit, and which anyone could look up if they cared to.
I don't think anything prevents anyone from just reverting or
modifying them if they're unsatisfied with them.

If you want GNU screen on plan9, go for it.  You can implement it
without even touching rio by using /dev/kbdtap.  You can also combine
that with riow and bar scripts.  There's literally nothing preventing
you from reimplementing your favorite unix terminal multiplexer or GNU
tool on plan9.  Of course, you probably already know all of this,
which is why you're reviving this discussion after someone failed to
quit sam or operate rio for a moment.  I didn't know about q being
standard though, I tried typing q in acme, but it doesn't work, what
gives?

qwx