Subject: Re: [9front] [PATCH] introduce code points above BMP to /lib/unicode
Date: Sun, 23 Oct 2022 10:28:34 -0400 [thread overview]
Message-ID: <331C03D74E035C4D8362827B9D652348@eigenstate.org> (raw)
> On Mon Oct 17 22:28:26 +0200 2022, email@example.com 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.
next prev parent reply other threads:[~2022-10-23 14:29 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-17 5:24 Jacob Moody
2022-10-17 6:34 ` qwx
2022-10-17 20:28 ` Jacob Moody
2022-10-23 5:07 ` qwx
2022-10-23 14:28 ` ori [this message]
2022-10-23 16:58 ` qwx
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).