From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#55319: 28.1.50; Abugida not rendered correctly (MacOS) Date: Thu, 12 May 2022 12:54:39 +0300 Message-ID: <83k0aroz34.fsf@gnu.org> References: <83ilqgufm3.fsf@gnu.org> <83czgnv3ak.fsf@gnu.org> <052FC289-9179-4B2D-AE52-2D688410162C@gmail.com> <87zgjn41db.fsf@gmail.com> <56617540-B9BC-4769-BE87-24935CBAA99C@gmail.com> <87r14z406q.fsf@gmail.com> <83mtfnozv3.fsf@gnu.org> <87ilqb3x4v.fsf@gmail.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="37499"; mail-complaints-to="usenet@ciao.gmane.io" Cc: justksqsf@gmail.com, 55319@debbugs.gnu.org To: Robert Pluim Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu May 12 12:18:37 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1np5u0-0009dL-UI for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 12 May 2022 12:18:37 +0200 Original-Received: from localhost ([::1]:51180 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1np5tz-0001Bf-Ek for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 12 May 2022 06:18:35 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44360) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1np5XC-0003EE-Dx for bug-gnu-emacs@gnu.org; Thu, 12 May 2022 05:55:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:45819) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1np5XC-0002c7-2X for bug-gnu-emacs@gnu.org; Thu, 12 May 2022 05:55:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1np5XB-0000bT-Un for bug-gnu-emacs@gnu.org; Thu, 12 May 2022 05:55:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 12 May 2022 09:55:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 55319 X-GNU-PR-Package: emacs Original-Received: via spool by 55319-submit@debbugs.gnu.org id=B55319.16523492832285 (code B ref 55319); Thu, 12 May 2022 09:55:01 +0000 Original-Received: (at 55319) by debbugs.gnu.org; 12 May 2022 09:54:43 +0000 Original-Received: from localhost ([127.0.0.1]:39716 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1np5Wt-0000an-4i for submit@debbugs.gnu.org; Thu, 12 May 2022 05:54:43 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:50990) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1np5Ws-0000aZ-0g for 55319@debbugs.gnu.org; Thu, 12 May 2022 05:54:42 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:60426) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1np5Wm-0002Zp-Lo; Thu, 12 May 2022 05:54:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=zHuV0aE1zrnq9K5io+UblubmbbBVCIFMgtumIr7UFiw=; b=IHXqGcq8aY48 guKg9eA4plf2vgxqD5xnXjzSSiPHECNRBsDUPr3MEWnfpDDJl9r+ojNuoG0EpqLKfVfOclzphiLpZ Np9iHP9TrLRzb8vJg6e1KgNQbmvctaCiT4CQzToR8h9R65kaTb/ffXJ/WbTas747A0sMGqJ3pGXK9 ZYyl8kbjeJt8B9/n/baQBJ6YXTnr+QwLEDqJcuYXMZPiIPYFEWN6nU3A3L2TOG/x8jzTaMyWDOtEd /HC9p8T3oDX/plZbhl6pAAsw3FUzPFJI3umafbRILgOitphSmCV7fmxUcLCgFDNyVxcMgkFW1bDb0 HGOXhnIfXE0voN9zu/n/vQ==; Original-Received: from [87.69.77.57] (port=1232 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1np5Wm-0007Wk-5L; Thu, 12 May 2022 05:54:36 -0400 In-Reply-To: <87ilqb3x4v.fsf@gmail.com> (message from Robert Pluim on Thu, 12 May 2022 11:42:24 +0200) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:232034 Archived-At: > From: Robert Pluim > Cc: justksqsf@gmail.com, 55319@debbugs.gnu.org > Date: Thu, 12 May 2022 11:42:24 +0200 > > >>>>> On Thu, 12 May 2022 12:37:52 +0300, Eli Zaretskii said: > > >> From: Robert Pluim > >> Cc: 55319@debbugs.gnu.org, Eli Zaretskii > >> Date: Thu, 12 May 2022 10:36:29 +0200 > >> > >> Eli, since these are PUA, can we still add them to Emacs? > > Eli> I don't think I understand what exactly would you like to add. > > The composition rules that Kai Ma just produced. Those composition rules assume a specific meaning to these PUA codepoints. But if someone uses those same PUA codepoints to express other characters, the composition rules will no longer be valid for that someone. This is a general problem with PUA codepoints: their meaning is in the eyes of the beholder. We could perhaps provide some infrastructure for making use of PUA codepoints easier than it is now. We could even provide opt-in packages, which, when loaded, assign specific meanings to specific PUA codepoints. But I don't see how we could _by_default_ assign some specific meaning to those codepoints, because there's no basis for preferring one interpretation of them to another.