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.tangents Subject: Re: Display of undisplayable characters: \U01F3A8 instead of diamond Date: Fri, 2 Sep 2022 21:52:44 +0000 Message-ID: References: <2f302d1c3966849477b3@heytings.org> <83mtbiovzr.fsf@gnu.org> <83a67hq3l7.fsf@gnu.org> <878rn1zk52.fsf@dataswamp.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="29231"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-tangents@gnu.org To: chad Original-X-From: emacs-tangents-bounces+get-emacs-tangents=m.gmane-mx.org@gnu.org Fri Sep 02 23:53:45 2022 Return-path: Envelope-to: get-emacs-tangents@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 1oUEbh-0007Pg-55 for get-emacs-tangents@m.gmane-mx.org; Fri, 02 Sep 2022 23:53:45 +0200 Original-Received: from localhost ([::1]:59428 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oUEbf-0002Jx-Mu for get-emacs-tangents@m.gmane-mx.org; Fri, 02 Sep 2022 17:53:43 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36816) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oUEap-0001TE-3y for emacs-tangents@gnu.org; Fri, 02 Sep 2022 17:52:52 -0400 Original-Received: from mx3.muc.de ([193.149.48.5]:38686) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oUEam-0004m2-0r for emacs-tangents@gnu.org; Fri, 02 Sep 2022 17:52:49 -0400 Original-Received: (qmail 27145 invoked by uid 3782); 2 Sep 2022 23:52:45 +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 23:52:44 +0200 Original-Received: (qmail 10913 invoked by uid 1000); 2 Sep 2022 21:52:44 -0000 Content-Disposition: inline In-Reply-To: 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=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-tangents@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emacs news and miscellaneous discussions outside the scope of other Emacs mailing lists List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-tangents-bounces+get-emacs-tangents=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-tangents" Xref: news.gmane.io gmane.emacs.tangents:907 Archived-At: Hello, Chad. On Fri, Sep 02, 2022 at 16:39:29 -0400, chad wrote: > On Fri, Sep 2, 2022 at 3:25 PM Emanuel Berg wrote: > > > I understand (academically) that once someone has adapted > > > themselves to a particular set of bugs, shortcomings, and > > > limitations > > But here the bug was actually better from our perspective ... > The bug was better in that the undefined behavior from sending known-bad > data to the console hasn't yet caused you trouble that you've identified. We weren't talking about bad data. We were talking about sending valid UTF-8 sequences to the Linux console. This console is programmed to handle these correctly, whether or not there is a matching font entry for that UTF-8 sequence. > Everyone (who's looked at the code) acknowledges that it was doing the > wrong thing. This is untrue. I've looked at the code, and consider it was doing the right thing. In fact, I've perused the Linux console code too, and vaguely remember its handling of glyph-less outputs. > The fact that the bug didn't hurt you and you got used to it is > exactly what I meant by "adapted themselves". What bug? I can't see a bug. But I've already half-volunteered to work on it. Maybe other console types don't handle random UTF-8 byte sequences well. I don't know. But Linux does. > What the other user (RMS, in this case) _wanted_ to do was to use a console > (not window system) emacs to look at a range of characters that extends > beyond ASCII. Of course. So do I. The Linux console is designed and implemented to support characters beyond ASCII. It's restriction is to 256 distinct character glyphs. > The specific implementations he was using did that right some of the > time and wrong some of the time. Too many pronouns. What are you saying? To what are you referring by "specific implementations"? Implementations of what? You're saying these implementations did "that" right some of the time. What does "that" refer to? What do you mean by wrong? > When it was wrong, it failed in a certain way. He adapted himself to > that failure. I don't see any failure. Richard's complaint was that characters without glyphs were getting displayed as long hex strings rather than the "diamond" that they were previously displayed as. I think the complaint has merit. It seems to me to be a classic case for a user option. > The alternative that emacs-devel is trying to establish (via experiments, > etc/PROBLEMS changes, and perhaps code patches) will make the system fail > less often -- that is, do what the user wants more often. The argument in > question is basically "Don't make the software do what the user wants more > often if it changes away from the bugs that are already familiar to me", > especially when that argument is expressed *in the middle of fixing the > problem*, as a discouragement from fixing the problem for all users, then > we've arrived at "That's horrifying." ala XKCD 1172. ???? > ~Chad -- Alan Mackenzie (Nuremberg, Germany).