9front - general discussion about 9front
 help / color / mirror / Atom feed
From: ori@eigenstate.org
To: 9front@9front.org
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)
In-Reply-To: <CD2D7AE37383C526FCB4128A999B711C@wopr.sciops.net>

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.


  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

Reply instructions:

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=331C03D74E035C4D8362827B9D652348@eigenstate.org \
    --to=ori@eigenstate.org \
    --cc=9front@9front.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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).