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.devel Subject: Re: character sets as they relate to =?utf-8?B?4oCcUmF34oCd?= string literals for elisp Date: Thu, 07 Oct 2021 10:01:10 +0300 Message-ID: <83r1cx1fpl.fsf@gnu.org> References: <87v92ft9z6.fsf@db48x.net> <87o885tyle.fsf@db48x.net> <83k0it6lu5.fsf@gnu.org> <87k0isu7hz.fsf_-_@db48x.net> <87a6jotszy.fsf@db48x.net> <875yuctout.fsf@db48x.net> <87wnmrs8lq.fsf@db48x.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="2403"; mail-complaints-to="usenet@ciao.gmane.io" Cc: db48x@db48x.net, acm@muc.de, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Oct 07 09:11:30 2021 Return-path: Envelope-to: ged-emacs-devel@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 1mYNYw-0000Ry-4x for ged-emacs-devel@m.gmane-mx.org; Thu, 07 Oct 2021 09:11:30 +0200 Original-Received: from localhost ([::1]:41594 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mYNYu-0006mk-8B for ged-emacs-devel@m.gmane-mx.org; Thu, 07 Oct 2021 03:11:28 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36004) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mYNP9-0005Yw-3H for emacs-devel@gnu.org; Thu, 07 Oct 2021 03:01:24 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:54682) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mYNP7-0007h2-4R; Thu, 07 Oct 2021 03:01:21 -0400 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2412 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 1mYNP0-00025V-Jt; Thu, 07 Oct 2021 03:01:14 -0400 In-Reply-To: (message from Richard Stallman on Wed, 06 Oct 2021 16:54:17 -0400) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:276479 Archived-At: > From: Richard Stallman > Cc: acm@muc.de, eliz@gnu.org, monnier@iro.umontreal.ca, > emacs-devel@gnu.org > Date: Wed, 06 Oct 2021 16:54:17 -0400 > > > Ah, I think I understand what you are getting at. You are asking why raw > > strings should use ｢｣? > > On a Linux console, that shows as two diamonds followed by a question mark. > That's no good for special syntactic delimiters. > > Indeed, to use non-ASCII characters for such jobs would be a radical > change. In things like this, we must play safe. We can use the display-table feature to avoid the problems with such characters. We already do that with displaying doc strings in *Help* buffers, and when displaying Info manuals: we display those characters as their ASCII equivalents or equivalent ASCII strings. Of course, for this to work, Someone(TM) should identify the problematic characters and program Emacs to set up the display tables accordingly. The point to take from this discussion, IMO, is that we should carefully consider introduction of each such character, and arrange for the text using them to be legible on all supported display types. We cannot just willy-nilly add them to our sources and documentation and assume they will always be displayed correctly.