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: Fri, 02 Sep 2022 16:59:48 +0300 Message-ID: <83a67hq3l7.fsf@gnu.org> References: <87edx28cl1.fsf@disroot.org> <83y1v7w6eu.fsf@gnu.org> <2f302d1c3966849477b3@heytings.org> <83mtbiovzr.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="14652"; mail-complaints-to="usenet@ciao.gmane.io" Cc: gregory@heytings.org, rms@gnu.org, emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Sep 02 16:02:48 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 1oU7Fu-0003cd-Od for ged-emacs-devel@m.gmane-mx.org; Fri, 02 Sep 2022 16:02:46 +0200 Original-Received: from localhost ([::1]:59990 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oU7Ft-0004YF-6B for ged-emacs-devel@m.gmane-mx.org; Fri, 02 Sep 2022 10:02:45 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52434) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oU7DB-0003af-GW for emacs-devel@gnu.org; Fri, 02 Sep 2022 09:59:58 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:34148) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oU7D8-0000RR-Vm; Fri, 02 Sep 2022 09:59:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=mMAf25ouU4B2E0ecnHNHQkJeIsFIOtltzLW/1XYvvFw=; b=FdytpmUxRBNTDbLWGdUD vlM7XqO9YTlku5+DZnoxxG05wTXBpx7ZQ9ZFtdhoTJw3VpuXLKHLxkzPSxTKNj7V59jl1UApfwJPj Xv/fx2058ye09GQPpQau5wuCwSGPh6D/juNLmhgF21lpnpaUZLaDeXbLiUsEMJSlhU/mcNzkvKjok 9DHd1/fuZA8LJuhNyl0N7xskq9c7bZag5b2i556FatOMM66Z8MuKI1cDb76xzZvuz0m+EQvxlSrtm 7pO6CWDvW6EC86UEWI0xo+9K83rEOhk2JGu2IOtP3PdqS3tPAbSYgQ0psGJBOrQMj8FSgdyQsYwWB +J14qrN0fKUKdA==; Original-Received: from [87.69.77.57] (port=2044 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 1oU7D6-0003J5-4y; Fri, 02 Sep 2022 09:59:54 -0400 In-Reply-To: (message from Alan Mackenzie on Fri, 2 Sep 2022 13:39:51 +0000) 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:294556 Archived-At: > 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? > 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? 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? 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.) > > 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. 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? Please understand: you are _really_ using Emacs on a terminal that is unsuitable for 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. > Have there been any untoward effects reported, by sending valid > Unicode strings of bytes to the Linux console? Sorry, but I don't care. We will not send unsupported byte sequences to any terminal, not if I have anything to say about that. That's simply bad engineering. We have plenty of better, safer solutions.