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: Sun, 4 Sep 2022 11:23:43 +0000 Message-ID: References: <2f302d1c3966849477b3@heytings.org> <83mtbiovzr.fsf@gnu.org> <83a67hq3l7.fsf@gnu.org> <83mtbhneht.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="9352"; mail-complaints-to="usenet@ciao.gmane.io" Cc: rms@gnu.org, gregory@heytings.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Sep 04 13:26:05 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 1oUnlN-0002DT-1P for ged-emacs-devel@m.gmane-mx.org; Sun, 04 Sep 2022 13:26:05 +0200 Original-Received: from localhost ([::1]:58426 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oUnlL-0000ml-RE for ged-emacs-devel@m.gmane-mx.org; Sun, 04 Sep 2022 07:26:03 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33448) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oUnjO-0008OW-PN for emacs-devel@gnu.org; Sun, 04 Sep 2022 07:24:02 -0400 Original-Received: from mx3.muc.de ([193.149.48.5]:56150) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oUnjM-00022O-R8 for emacs-devel@gnu.org; Sun, 04 Sep 2022 07:24:02 -0400 Original-Received: (qmail 9218 invoked by uid 3782); 4 Sep 2022 13:23:44 +0200 Original-Received: from acm.muc.de (p2e5d5d90.dip0.t-ipconnect.de [46.93.93.144]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 04 Sep 2022 13:23:43 +0200 Original-Received: (qmail 15263 invoked by uid 1000); 4 Sep 2022 11:23:43 -0000 Content-Disposition: inline In-Reply-To: <83mtbhneht.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:294695 Archived-At: Hello, Eli. On Sat, Sep 03, 2022 at 09:44:46 +0300, Eli Zaretskii wrote: > > From: Richard Stallman > > Cc: acm@muc.de, gregory@heytings.org, emacs-devel@gnu.org > > Date: Fri, 02 Sep 2022 22:51:27 -0400 > > > How can Emacs know which characters does your Linux console actually > > > support, out of all the Unicode range? > > A few days ago you said it could use char-displayable-p > > to determine this. If that works, it solves the problem of finding out > > which characters to display as diamond. > It works, but looping over all the Unicode characters is very slow, so > doing that at each startup would be unacceptable. If someone needs, I > can show a simple code to be run by the user, once, on the Linux > console, that would allow then to determine the codepoint ranges for > which the U+FFFD (or any other) replacements are needed, so that users > could run that code, and then put such customizations in their init > files. We could even have a special command to do that, if people > think it's important and helpful. > But all I hear till now is flat rejection of that solution, which is a > very weak incentive (to say the least) to work on such a command. I will start working on this soon (if nobody else does in the meantime). > > As for how, it would be asy to add a variable whose value should be a > > vector containing integers, or a single-byte string, saying what to > > send. This will be adequate for a Linux console, and it doesn't need > > to handle anything else. > You are describing what display-tables provide. That's the solution I > recommend if you really want to see those U+FFFD "diamonds" instead of > the characters that cannot be displayed. I see no reason for yet > another solution for a problem for which we already have two > (glyphless-char-display and display-tables). I envisage having a minor mode specific to the Linux console, which when enabled for the first time will do the loop over all Unicode characters testing them for glyps, and create the display table. This can then be stored in .emacs in the customisation section. When the mode is enabled, this display table will be used to output the \ufffd's. When disabled, the glyphless characters will get printed as hex strings, as currently. Possibly this will involve having two display tables which will get swapped when the mode is en/disabled. Or something like that. This should work well for a user who doesn't frequently change her Linux console font settings. -- Alan Mackenzie (Nuremberg, Germany).