From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from yow.a-b.xyz ([45.32.152.219]) by ewsd; Sat May 16 17:03:43 EDT 2020
Received: 
	by yow.a-b.xyz (OpenSMTPD) with ESMTPSA id d5db94ac (TLSv1.2:ECDHE-RSA-AES256-SHA:256:NO)
	for <9front@9front.org>;
	Sat, 16 May 2020 23:03:38 +0200 (CEST)
Message-ID: <7DFF0818D7A447656BCEDD9A53228F35@a-b.xyz>
To: 9front@9front.org
Subject: Re: [9front] [PATCH] rio: add -label wctl param; improve window(1)
Date: Sat, 16 May 2020 21:05:01 +0200
From: kvik@a-b.xyz
In-Reply-To: <82412A1ACD62CDC4DB0267615A344641@felloff.net>
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: browser rails frontend 

> maybe, but parsewctlmsg() in this form is not up to the task. you can't
> have labels with spaces in them for example.

Hm, if we do it in steps maybe that's an opportunity to avoid the
breakage as well!  Something like:
* rewrite the wctl parser to properly handle argument lists,
	* make it *ignore* the -label NAME parameter,
* wait for a while and shame people into sysupdate,
* land the label-related window(1) changes.

This way when the new window(1) is eventually pulled it will break
label-setting until a new rio is compiled and started, but everything
will otherwise continue working, which is much less of a breakage than
refusing to spawn windows entirely.