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: Display of undisplayable characters: \U01F3A8 instead of diamond Date: Sun, 28 Aug 2022 09:10:13 +0300 Message-ID: <831qt0zynu.fsf@gnu.org> References: <834jxz33m9.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="23735"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Aug 28 08:11:43 2022 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 1oSBWI-00060P-RK for ged-emacs-devel@m.gmane-mx.org; Sun, 28 Aug 2022 08:11:43 +0200 Original-Received: from localhost ([::1]:60358 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oSBWH-000527-8g for ged-emacs-devel@m.gmane-mx.org; Sun, 28 Aug 2022 02:11:41 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53358) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oSBUe-0004IH-Dw for emacs-devel@gnu.org; Sun, 28 Aug 2022 02:10:01 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:44184) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oSBUc-0008H3-W3 for emacs-devel@gnu.org; Sun, 28 Aug 2022 02:10:00 -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=pKnQcy7DUwc7JPNEk5IykrIMPmPzpINJ5W+8MR99NFs=; b=fHhqY1z8p8TZ REDBDGTMvgdxyO6PS7lKiaTCxPOGnXUXGv/yagaCdp35YQGzQa78dta2PMFpp3+ZrZark+xF3PUI8 jPIwklup1y733BnvuLHEoK1tqKjiMX6YOUmS8dJHdgI9hGOs6j5Z13p+e86X2q1S9/pUbMUJr3xme XygUdibPj2j48FnVMyfTjVXDsG6rBLDUYrzRf4igYVQbC9DRlEdo0SinSKjD1boQS05XyGwh/sWOv w4B5VknpgYO9ErewL/6EtlmbAn4ENKo5KNdN9HOPIQ6VPYttfYt08OuLobmSe32cLmEIsBnCLXiDH jRowOKuupZiptWdXv7ukQw==; Original-Received: from [87.69.77.57] (port=4769 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 1oSBUa-0007HQ-TQ; Sun, 28 Aug 2022 02:09:57 -0400 In-Reply-To: (message from Richard Stallman on Sun, 28 Aug 2022 00:04:51 -0400) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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:294209 Archived-At: > From: Richard Stallman > Cc: emacs-devel@gnu.org > Date: Sun, 28 Aug 2022 00:04:51 -0400 > > > Is this specifically about that U+1F3A8 character? Or is this more > > general? > > This applies to all characters that display that way. I don't know > what U+1F3A8 stands for; to me, it is simply "some undisplayable character." In that case, you can significantly improve the situation by typing M-x latin1-display-ucs-per-lynx RET or by using "M-x customize-variable" to customize the variable latin1-display-ucs-per-lynx to a non-nil value. Then many non-ASCII characters will be displayed as ASCII emulations. Some characters will inevitably be still not displayable; for those you can define their ASCII representation like this: (set-char-table-extra-slot glyphless-char-display 0 "*") Then the characters that cannot be displayed will be represented by the string that is the last argument to set-char-table-extra-slot, with a special face designed to make those stand out. The string must be ASCII, though, because nothing else is safe to serve as fallback. (With the latest master branch, if the string is a single character, it will not be enclosed in [..], so you can effectively use that single character as a replacement character for those your terminal cannot display. It still has to be an ASCII character.) > > This is a standard Emacs way of displaying unsupported characters on > > TTY frames. I fail to see how this is worse than displaying the same > > diamond glyph for any unsupported character, because with the > > character codes you at least know when the characters are different, > > even without "C-u C-x =". > > This change makes it harder to see and recognize the displayable > characters in the line. I don't think I understand how this is possible. The \Unnnn thing has a distinct face. Maybe you need to customize that face to make it stand out on your terminal? > When a line contains many nondisplayable characters, this change makes it > much longer, so the line gets continued. Only if the line is already long, which is not necessarily true. Let's not exaggerate problems too much, okay? > In practice, I can't recognize when the same \U sequence appears more > than once on the screen. I can't see what the hex digits are just > with a glance; only if I concentrate and read one. If I do that, I > can't recognize other instances of the same sequence without > concentrating on each of them to read it. This still sounds like an exaggeration to me. If you care about those characters, you should not have any difficulties realizing which are identical and which aren't. For several instances of the same character, you need to type "C-u C-x =" just once. So this is an improvement vs the identical display of all the undisplayable characters, where you must type "C-u C-x =" for each one of them. If you don't care what those characters are, then you just don't need to waste any time thinking what they could be and which ones are different. So here, there's no disadvantage to the current display. > > What > > you saw before was a bug in the way Emacs detected which characters > > the Linux console is capable of displaying. > > I am surprised. I thought of the diamond display as a feature; ISTR > we discussed it as such. But maybe I'm mistaken. You are mistaken. It was never a feature. > Either way, I'd much rather have the diamonds. You can have any ASCII character (see above) or a string of characters instead. But not the diamond, which is a non-ASCII character.