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,
	NICE_REPLY_A,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no
	version=3.4.4
Received: (qmail 9140 invoked from network); 24 Aug 2022 20:16:22 -0000
Received: from 9front.inri.net (168.235.81.73)
  by inbox.vuxu.org with ESMTPUTF8; 24 Aug 2022 20:16:22 -0000
Received: from mail.posixcafe.org ([45.76.19.58]) by 9front; Wed Aug 24 16:10:23 -0400 2022
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=posixcafe.org;
	s=20200506; t=1661371819;
	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:references:references;
	bh=uQy5sORM8/JnTb0P2J5jMRxLSoF5gD2l9MWdrjCwhtI=;
	b=oPFnVVCalbZVHsUhke8BpVjiZRdmTQ79F+l08wMjKZ24oHButXeoaUc15+80AokW77UHfM
	hyM0s2ypg9WfSVbazsB3jIo4hgQ5iuDtPm7VFrIJBHgDrXTHHASvXKfPODvhrHPDweIGa/
	0vLg8t3KWlUnQDQGMT/oddp2YXqAHwg=
Received: from [192.168.168.200] (161-97-228-135.mynextlight.net [161.97.228.135])
	by mail.posixcafe.org (OpenSMTPD) with ESMTPSA id 66f90b71 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO)
	for <9front@9front.org>;
	Wed, 24 Aug 2022 15:10:18 -0500 (CDT)
Message-ID: <afa3cfb0-00a5-b15d-ef62-964cfd81323a@posixcafe.org>
Date: Wed, 24 Aug 2022 14:10:16 -0600
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.10.0
Content-Language: en-US
To: 9front@9front.org
References: <D32244BE8BCD42913EFB7C13CB7878C0@eigenstate.org>
 <6381c6d9cb1ff9f2@orthanc.ca>
 <CABB-WO9dEVJS8F08h7HMmhAjmqwpOZwJReS_t=5g+4cVffzyHg@mail.gmail.com>
From: Jacob Moody <moody@mail.posixcafe.org>
In-Reply-To: <CABB-WO9dEVJS8F08h7HMmhAjmqwpOZwJReS_t=5g+4cVffzyHg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
List-ID: <9front.9front.org>
List-Help: <http://lists.9front.org>
X-Glyph: ➈
X-Bullshit: blockchain pipelining database 
Subject: Re: [9front] [PATCH] programmable menus for rio
Reply-To: 9front@9front.org
Precedence: bulk

On 8/24/22 13:31, Stuart Morrow wrote:
> On 24/08/2022, Lyndon Nerenberg (VE7TFX/VE6BBM) <lyndon@orthanc.ca> wrote:
>> [ something about new /dev files ]
> 
> I don't get why kbdtap is in rio rather than kbdfs.

I wanted information known only to rio, namely when
a user switches windows so ktrans knows when to reset the
line buffer. I originally had this communicated via
a message through kbdtap. That is no longer the case
pending me figuring a better way of communicating
this information. There isn't much of a technical reason
for why kbdtap couldn't exist within kbdfs. I do enjoy
that I can run a kbdtap program in a subrio for testing
and have it isolated there. But this has been something
I've thought about. I haven't convinced myself enough
to allot the time to do the rewrite.

On 8/24/22 12:56, Lyndon Nerenberg (VE7TFX/VE6BBM) wrote:
> Given that rio has had a couple of decades to bake, the
> world has changed around it, and thinking of new stuff
> is always a good idea.  But diddling with rio just seems
> a path to feechur bloat.  If you really want to try new
> things, it's best to start from the ground up (IMO).
> But the joy of rio is you can write and experiment with
> your new stuff inside of rio, without breaking your
> existing environment.

I think most would agree that a rio rewrite could be
very nice. But let's not pretend that is an easy
task. I want to be cautious about blocking any
forward movement or experimentation for some
mythical rewrite. Especially since it seems no one
has expressed enough interest to actually start
working on it.

I think I am starting to learn why people
don't enjoy working on rio. Disregarding the code, it
seems like its impossible to make a change that someone
isn't disgruntled with.

-- moody