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.0 required=5.0 tests=none autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 11524 invoked from network); 23 Oct 2022 14:29:45 -0000 Received: from 9front.inri.net (168.235.81.73) by inbox.vuxu.org with ESMTPUTF8; 23 Oct 2022 14:29:45 -0000 Received: from mimir.eigenstate.org ([206.124.132.107]) by 9front; Sun Oct 23 10:28:38 -0400 2022 Received: from abbatoir (pool-108-27-53-161.nycmny.fios.verizon.net [108.27.53.161]) by mimir.eigenstate.org (OpenSMTPD) with ESMTPSA id 20892d94 (TLSv1.2:ECDHE-RSA-AES256-SHA:256:NO) for <9front@9front.org>; Sun, 23 Oct 2022 07:28:35 -0700 (PDT) Message-ID: <331C03D74E035C4D8362827B9D652348@eigenstate.org> To: 9front@9front.org Date: Sun, 23 Oct 2022 10:28:34 -0400 From: ori@eigenstate.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: virtualized TOR plugin deep-learning locator Subject: Re: [9front] [PATCH] introduce code points above BMP to /lib/unicode Reply-To: 9front@9front.org Precedence: bulk Quoth qwx@sciops.net: > 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. Currently 9front only works well with the latinoid languages, and with Moody's work, I suspect passably with Chinese and Japanese. Languages like hebrew (the only non-latin language I know) are unusable, though with hebrew the larger problem is the lack of right to left support. as far as what people do when it's missing? use english; I can't do hebrew on 9front. doesn't work. saying "it will never work" is an option; I think our UI will always be in English, for example, but it seems like it would be a nice goal to type and view any language correctly. at the same time, it *is* a lot of complexity. > > [...] 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. In hebrew input, at least, I'd expect the opposite; I think it will end up depending on culture what behavior is 'normal', but on this sort of thing, we can set our own expectations.