From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: etc/HELLO markup etc. Date: Fri, 28 Dec 2018 09:10:53 +0200 Message-ID: <835zve6s8y.fsf@gnu.org> References: <3fd27fe5-e650-b207-fdd4-36f805b89b4d@cs.ucla.edu> <83bm5hcroa.fsf@gnu.org> <9f33127d-f01b-b138-7a0c-ffeac7b77938@cs.ucla.edu> <835zvochdj.fsf@gnu.org> <5f113128-36c9-30c6-3413-8dc36051e058@cs.ucla.edu> <83va3nban3.fsf@gnu.org> <838t0iasju.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1545981891 959 195.159.176.226 (28 Dec 2018 07:24:51 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 28 Dec 2018 07:24:51 +0000 (UTC) Cc: eggert@cs.ucla.edu, monnier@iro.umontreal.ca, Emacs-devel@gnu.org To: Kenichi Handa Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Dec 28 08:24:47 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gcmVi-000096-JE for ged-emacs-devel@m.gmane.org; Fri, 28 Dec 2018 08:24:46 +0100 Original-Received: from localhost ([127.0.0.1]:57302 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gcmXp-0003jV-9Z for ged-emacs-devel@m.gmane.org; Fri, 28 Dec 2018 02:26:57 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:57864) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gcmWi-0002UZ-Ll for Emacs-devel@gnu.org; Fri, 28 Dec 2018 02:25:52 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gcmIK-0006Oq-E9 for Emacs-devel@gnu.org; Fri, 28 Dec 2018 02:10:57 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:52316) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gcmIF-0006IG-K5; Fri, 28 Dec 2018 02:10:51 -0500 Original-Received: from [176.228.60.248] (port=4094 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1gcmIF-0006Ql-7d; Fri, 28 Dec 2018 02:10:51 -0500 In-reply-to: <838t0iasju.fsf@gnu.org> (message from Eli Zaretskii on Sat, 22 Dec 2018 10:12:37 +0200) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:232015 Archived-At: Ping! Kenichi, could you please comment on this issue? TIA. > Date: Sat, 22 Dec 2018 10:12:37 +0200 > From: Eli Zaretskii > Cc: handa@gnu.org, monnier@iro.umontreal.ca, Emacs-devel@gnu.org > > > Cc: handa@gnu.org, monnier@iro.umontreal.ca, > > Emacs Development > > From: Paul Eggert > > Date: Fri, 21 Dec 2018 13:07:09 -0800 > > > > [removing 33796@debbugs.gnu.org and adding emacs-devel@gnu.org to cc list] > > I've changed the Subject, as the original one was too similar to the > bug report. > > > Eli Zaretskii wrote: > > > Which markup is not necessary for display, in your opinion? > > > > At most all that's useful is markup that distinguishes Chinese and Japanese > > variants of Han characters; this might also include hanja (Korean) and Chữ Nôm > > (Vietnamese) variants if we ever added such characters to etc/HELLO. Such markup > > might be useful because a significant set of east Asian users dislike Unicode's > > Han unification and prefer specific variants of Han characters. I'm not aware of > > any other set of users who dislike unification in that way. > > I'm not yet sure this is only about Han unification. Using charsets > for specifying fonts is a general feature in Emacs, which can be used > to control which fonts are selected independently of what the OS > facilities such as fontconfig do. > > I hope Handa-san will be able to comment on this stuff. > > If Han unification is the only important user of the charset property, > then yes, we could remove the rest of the charset info from HELLO. > But please realize that the current HELLO just keeps the information > that was there before recoding it in UTF-8, nothing was added. It is > just kept in a different form, which makes the charset info > human-readable, where previously it was encoded in the ISO 2022 > sequences. > > > > That markup is precisely what keeps the charset properties on the > > > corresponding greetings. Removing it would be losing information that > > > HELLO is trying to preserve. > > > > Although the etc/HELLO markup might be of interest to those who care about > > annotating languages in the text, it's irrelevant to the ordinary purpose of > > that file, which is to show textual translations of "Hello" > > That's not the original purpose of that file. The purpose is to show > scripts, not languages, and to show how we display different scripts > in the same buffer. > > > It's still not a good user interface, though, as it is difficult to see the > > markup's effect when visiting etc/HELLO in the usual way > > If the usual way is via find-file and its ilk, then you should see the > same results as with "C-h h", so I'm not sure I understand what you > mean here. > > > etc/HELLO is littered with so much useless markup > > I disagree that it's useless. Most of it is useful. > > > the effect of markup errors is so subtle, and it's so much of a pain > > to edit the markup in its ordinary form of display > > If you mean manually editing the markup, then you aren't supposed to > do that. > > In what way most of what you say is not applicable to etc/enriched.txt > in general? If you just dislike what Enriched mode produces on disk, > then let's stop this argument, as you seem to be arguing against files > with markup in general, and that's a non-starter for me. > > > the file is not a good showroom for how to maintain multilingual > > text. > > What other facilities are you aware of or can suggest for showing > multilingual text with such level of detail and precision? > > > It's not a good sign that there seem to be errors in the > > possibly-useful (i.e., CJ) markup that nobody has noticed since the > > markup was introduced in May, and that I noticed these errors now > > only because I was visiting the file literally. > > Which errors? I don't think we discovered any errors. We may have > discovered some markup on whitespace where we perhaps could do without > it (I'm not yet sure of that), but that's all, and is not necessarily > an error. > >