unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Paul Eggert <eggert@cs.ucla.edu>
To: "Clément Pit-Claudel" <cpitclaudel@gmail.com>, emacs-devel@gnu.org
Subject: Re: Emacs release schedule and Akihito's abdication
Date: Fri, 27 Jul 2018 16:41:44 -0700	[thread overview]
Message-ID: <6019f365-6417-ac5f-4963-93adadcfe132@cs.ucla.edu> (raw)
In-Reply-To: <2de88b1c-f576-d009-80ae-8581227463fa@gmail.com>

Clément Pit-Claudel wrote:
> Can you clarify how Japanese text would break?

Sorry, I don't know exactly. One thing is that the regular expression 
[[:alpha:]] wouldn't match the new character even though it'll be alphabetic. 
Although I expect more issues will arise, not being a heavy-duty Japanese user I 
don't know what they'll be.

 From the Unicode point of view, the issue is not merely assigning a code point 
for the new character (that's already done: it'll be U+32FF), it's assigning 
compatibility decompositions, something that won't be known until the new 
emperor chooses his name. For example, the current emperor's name ㍻ (U+337B) is 
a composition of 平成 (U+5E73, U+6210). Because decompositions must be cast in 
stone before the code point is officially issued, Unicode won't update its 
tables until it knows the actual name and how it's composed. And because it 
won't update its tables, I expect that Emacs (and other software apps) will wait 
until it does, which means that older programs may well mishandle the new character.

The new emperor could help out by choosing a name now, but Japanese imperial 
protocol long predates Unicode and I expect they're not gonna change how they do 
things just because some young whippersnapper computer dudes ask them to.

Also, suppose the new emperor decides on a single-character name that's already 
in Unicode; presumably U+32FF will not be assigned to the name after all. I 
think this unlikely, though, as getting a character of your own is one of the 
perks of being emperor.

There are other possibilities, including the unexpected death of an emperor 
(things get pretty complicated for dates, but I expect for text it's merely just 
keeping a catalog of all the names).



  reply	other threads:[~2018-07-27 23:41 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-27 20:20 Emacs release schedule and Akihito's abdication Paul Eggert
2018-07-27 20:35 ` John Wiegley
2018-07-27 21:17 ` Eli Zaretskii
2018-07-27 23:36   ` Paul Eggert
2018-07-27 21:38 ` Clément Pit-Claudel
2018-07-27 23:41   ` Paul Eggert [this message]
2018-07-28  5:00     ` Clément Pit-Claudel
2018-07-28  7:09       ` Eli Zaretskii
2018-07-28 11:08   ` Van L
2018-07-28 20:53     ` Paul Eggert

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

  List information: https://www.gnu.org/software/emacs/

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

  git send-email \
    --in-reply-to=6019f365-6417-ac5f-4963-93adadcfe132@cs.ucla.edu \
    --to=eggert@cs.ucla.edu \
    --cc=cpitclaudel@gmail.com \
    --cc=emacs-devel@gnu.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.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).