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: Display of undisplayable characters: \U01F3A8 instead of diamond Date: Fri, 2 Sep 2022 16:12:12 +0000 Message-ID: References: <83y1v7w6eu.fsf@gnu.org> <2f302d1c3966849477b3@heytings.org> <83mtbiovzr.fsf@gnu.org> <83a67hq3l7.fsf@gnu.org> 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="37751"; mail-complaints-to="usenet@ciao.gmane.io" Cc: gregory@heytings.org, rms@gnu.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Sep 02 18:14:57 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 1oU9Jo-0009ao-V8 for ged-emacs-devel@m.gmane-mx.org; Fri, 02 Sep 2022 18:14:56 +0200 Original-Received: from localhost ([::1]:47634 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oU9Jn-0006j4-R7 for ged-emacs-devel@m.gmane-mx.org; Fri, 02 Sep 2022 12:14:55 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53140) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oU9HK-0003o8-3x for emacs-devel@gnu.org; Fri, 02 Sep 2022 12:12:22 -0400 Original-Received: from mx3.muc.de ([193.149.48.5]:29857) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oU9HE-0006uK-1g for emacs-devel@gnu.org; Fri, 02 Sep 2022 12:12:21 -0400 Original-Received: (qmail 65435 invoked by uid 3782); 2 Sep 2022 18:12:13 +0200 Original-Received: from acm.muc.de (p2e5d5e67.dip0.t-ipconnect.de [46.93.94.103]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Fri, 02 Sep 2022 18:12:12 +0200 Original-Received: (qmail 9277 invoked by uid 1000); 2 Sep 2022 16:12:12 -0000 Content-Disposition: inline In-Reply-To: <83a67hq3l7.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.5; envelope-from=acm@muc.de; helo=mx3.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, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=unavailable autolearn_force=no X-Spam_action: no action 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:294572 Archived-At: Hello, Eli. On Fri, Sep 02, 2022 at 16:59:48 +0300, Eli Zaretskii wrote: > > Date: Fri, 2 Sep 2022 13:39:51 +0000 > > Cc: gregory@heytings.org, rms@gnu.org, emacs-devel@gnu.org > > From: Alan Mackenzie > > > > I agree with Richard that there should be an option for displaying > > > > characters outside of the current font as "�" rather than "\u2022". > > > I already explained how to set that up, so what exactly does the > > > "should be" part here want to say? > > The way you explained involves hacking Lisp > It involves writing some Lisp code and running it on your system, > yes. How is that a problem? It's not a problem for me, but might well be for other Linux console users. It really needs documenting somewhere, which might well be more work than just supplying an option. > > and finding out precise character ranges. That's a lot different > > from being able just to set an option. > How can Emacs know which characters does your Linux console actually > support, out of all the Unicode range? The console supports ALL characters in the Unicode range. Most of them it displays with the replacement character glyph, but it supports them all in the important sense of not crashing, or going unresponsive, or anything else like that. > And how can Emacs know which ones of those you want to see as their > ASCII "emulations" (per latin1-disp.el) and which you want to see as > U+FFFD replacements? It could examine the currently loaded font, if needed. But I was more thinking about allowing the console itself to do the replacement with \ufffd. > So yes, this requires you, the user, to tell Emacs which ones you want > to see in what manner. There are a lot of Unicode characters, so it > could be a large job, if the characters actually supported by the > console are all in distinct Unicode blocks. (But if you only want to > see Latin-1 characters, I've shown in this thread a one-liner to do > that. I guess you will reject that as well.) Some of the characters in my font lie outside the Latin-1 range. Doing this job properly requires writing some sort of script to examine the loaded font. I don't know how easy that would be. > > > There is already such a way in Emacs. Just use it, if that's what you > > > want. > > There appears to be no easy way to get the old behaviour back, where > > characters undisplayable on the console got displayed with \ufffd > > instead. You've characterised this old behaviour as a bug, but in > > the preferences of two actual Linux console users (Richard and > > myself), the solution is not better than the bug. > I don't understand why you are consistently rejecting every solution > that was suggested. Every solution suggested is either a lot of work, or is less good than how things were. > Including, amazingly enough, a way to actually produce the same > "diamond" glyphs on display under the same circumstances. Since when > do veteran Emacs hackers such as you and Richard consider some Lisp > coding a problem so grave as to justify flatly rejecting it? It doesn't scale. Without some sort of script, such as I suggested above, it has to be hacked individually for each setup. > Please understand: you are _really_ using Emacs on a terminal that is > unsuitable for it. For me, there is no better setup that I'm aware of. If there were, I would use it. > You _should_ expect problems. And when solutions are pointed out that > are just a few lines of Lisp away, I'd expect you to embrace them, not > flatly reject them. I would prefer a solution that would work for all Linux console users, including those who can't or don't want to hack Lisp. [ .... ] -- Alan Mackenzie (Nuremberg, Germany).