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 11848 invoked from network); 23 Oct 2022 05:09:27 -0000
Received: from 9front.inri.net (168.235.81.73)
  by inbox.vuxu.org with ESMTPUTF8; 23 Oct 2022 05:09:27 -0000
Received: from wopr.sciops.net ([216.126.196.60]) by 9front; Sun Oct 23 01:07:30 -0400 2022
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sciops.net; s=20210706;
	t=1666501534;
	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=egdve2k4V2DrVyPtJrm8PnH54S9WYvZAwpWe3eCcLys=;
	b=Oys+EejoVktgU6NnQZfW2xvY51lY/DOLrUhkfdh0OPnz1GTx4+GcmPoVU6VIMPbJKwDpbC
	gx0qfqxNvzz3xWY1tM++W0+cMkySfKVbC/6soi3EF+9406tco89wSXA3WevJM5lnNQQPDU
	JvSIZrUGwlVYoAJngAYp8GapCcF4VqI=
Received: 
	by wopr.sciops.net (OpenSMTPD) with ESMTPSA id 8c13f74b (TLSv1.2:ECDHE-RSA-CHACHA20-POLY1305:256:NO)
	for <9front@9front.org>;
	Sat, 22 Oct 2022 22:05:34 -0700 (PDT)
Message-ID: <CD2D7AE37383C526FCB4128A999B711C@wopr.sciops.net>
Date: Sun, 23 Oct 2022 07:07:23 +0200
From: qwx@sciops.net
To: 9front@9front.org
In-Reply-To: <ac9cdeb2-8b06-76ba-5f32-e65ed70bb32b@posixcafe.org>
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: full-stack interface component cache 
Subject: Re: [9front] [PATCH] introduce code points above BMP to /lib/unicode
Reply-To: 9front@9front.org
Precedence: bulk

On Mon Oct 17 22:28:26 +0200 2022, moody@mail.posixcafe.org wrote:
> Some additional discussion I'd like to get some input on is if we
> should just include the entirety of UnicodeData.txt.  There are some
> fields in there, notably decomposition mappings, that would be quite
> useful.  It would also be nice to generate the ranges used in things
> like runetype(2) from the upstream documents so that we can more
> easily keep up to date.
> 
> On this topic, I have been considering what should be done about
> compositional runes in general, as we currently do nothing with them.
[...]

I think that if this is of significant practical value and an
improvement in quality of life here, it should be done.  My question
is, and maybe I've missed an obvious answer, how often is this needed
or used in general, and what do people do when it's missing?  I
haven't been able to follow all of the discussions on input methods
and I don't know much about the subject, but I'm curious about how far
this must be pushed.


> [...] With this change, the
> combinational runes would essentially become zero width codepoints to
> the perspective of libdraw users.  Which means backspacing (without
> any changes) would require two(or more) hits to fully strike out the
> rune, progressively unwinding the modifications.  This makes sense to
> me, but I cant make assumptions about how others use these runes.

Again, I can't speak for anyone, but personally I'd always expect one
single backspace to erase any megarune, which is also what I've seen
in virtual keyboards on the shitphones I've touched.  I'd be very
confused if some characters in the middle of a sentence refuse to be
removed at once.

Anyway, thanks for looking into this!

Cheers,
qwx