From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: character sets as they =?utf-8?Q?relat?= =?utf-8?B?ZSB0byDigJxSYXfigJ0=?= string literals for elisp Date: Fri, 8 Oct 2021 17:17:36 +0000 Message-ID: References: <877der8smr.fsf@mail.linkov.net> <83y2772y0s.fsf@gnu.org> <83sfxd1g05.fsf@gnu.org> <83tuhtyn46.fsf@gnu.org> <83o880zuxs.fsf@gnu.org> <838rz4ypkt.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19281"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org, rms@gnu.org, juri@linkov.net, db48x@db48x.net, Stefan Kangas , yuri.v.khan@gmail.com, monnier@iro.umontreal.ca To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Oct 08 19:19:36 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 1mYtWw-0004mx-6z for ged-emacs-devel@m.gmane-mx.org; Fri, 08 Oct 2021 19:19:34 +0200 Original-Received: from localhost ([::1]:58468 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mYtWv-0000e5-9b for ged-emacs-devel@m.gmane-mx.org; Fri, 08 Oct 2021 13:19:33 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58968) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mYtVN-0007Dy-Df for emacs-devel@gnu.org; Fri, 08 Oct 2021 13:17:57 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:42915 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.90_1) (envelope-from ) id 1mYtVF-0007Yk-83 for emacs-devel@gnu.org; Fri, 08 Oct 2021 13:17:57 -0400 Original-Received: (qmail 74002 invoked by uid 3782); 8 Oct 2021 17:17:36 -0000 Original-Received: from acm.muc.de (p2e5d5cb1.dip0.t-ipconnect.de [46.93.92.177]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Fri, 08 Oct 2021 19:17:36 +0200 Original-Received: (qmail 8262 invoked by uid 1000); 8 Oct 2021 17:17:36 -0000 Content-Disposition: inline In-Reply-To: <838rz4ypkt.fsf@gnu.org> X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de Received-SPF: pass client-ip=193.149.48.1; envelope-from=acm@muc.de; helo=mail.muc.de X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=unavailable autolearn_force=no X-Spam_action: no action 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:276571 Archived-At: Hello, Eli. On Fri, Oct 08, 2021 at 09:53:54 +0300, Eli Zaretskii wrote: > > From: Stefan Kangas > > Date: Thu, 7 Oct 2021 20:37:19 -0400 > > Cc: rms@gnu.org, db48x@db48x.net, yuri.v.khan@gmail.com, emacs-devel@gnu.org, > > monnier@iro.umontreal.ca, juri@linkov.net [ .... ] > I'd rather not start another discussion of this [How to display em dash > in info], as opinions tend to be polarized about it, and IME nothing > can bridge over the differences of opinions in this matter. So I > prefer a different way of handling this, see below. > > I would hope that we could agree that how em dash is displayed is > > not necessarily strictly connected to "@documentencoding UTF-8"; and > > that it would be useful to continue using UTF-8 encoding, but also get > > the "old" way of displaying em dash. > Many people want to use and see Unicode punctuation characters in > human-readable text. That's a deliciously ambiguous sentence, with two opposite meanings. :-) I belong to the group of people who would rather see Unicode punctuation rendered in human-readable (i.e. ASCII) text. [ .... ] > So I'd prefer to deal with this differently: introduce a new > (buffer-local) minor mode, which will install a display-table, whereby > "problematic" Unicode characters will be displayed as their ASCII > equivalents or equivalent ASCII strings. We already set that up > automatically on terminals that are incapable of displaying those > characters, but nothing precludes us from having such a feature on > demand for capable displays as well. Then users who don't want the > effects of these characters on display could activate such a mode, and > solve their problems without affecting the actual contents of the Info > files. I would suggest something slightly different which will solve the entire problem rather than just part of it. Have the minor mode translate the buffer text (temporarily) into ASCII rather than just displaying it thus. That way the user can search for `foo' or ... simply by using C-s. -- Alan Mackenzie (Nuremberg, Germany).