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.bugs Subject: bug#57693: 29.0.50; Is there a more reliable version of `char-displayable-p'? Date: Sat, 10 Sep 2022 11:42:31 +0300 Message-ID: <831qsjboy0.fsf@gnu.org> References: <87v8pw1xyo.fsf@localhost> <83a678d5w6.fsf@gnu.org> <878rmr25tk.fsf@localhost> <83czc3bvbg.fsf@gnu.org> <87y1urybt6.fsf@localhost> <837d2bbr2s.fsf@gnu.org> <87edwjy77h.fsf@localhost> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25648"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 57693@debbugs.gnu.org To: Ihor Radchenko Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Sep 10 10:43:10 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1oWw50-0006WI-AT for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 10 Sep 2022 10:43:10 +0200 Original-Received: from localhost ([::1]:43696 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oWw4z-00011X-3U for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 10 Sep 2022 04:43:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:54360) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oWw4s-000118-Bp for bug-gnu-emacs@gnu.org; Sat, 10 Sep 2022 04:43:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:47853) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oWw4s-0006oR-0v for bug-gnu-emacs@gnu.org; Sat, 10 Sep 2022 04:43:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oWw4r-0004Me-PV for bug-gnu-emacs@gnu.org; Sat, 10 Sep 2022 04:43:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 10 Sep 2022 08:43:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 57693 X-GNU-PR-Package: emacs Original-Received: via spool by 57693-submit@debbugs.gnu.org id=B57693.166279937916768 (code B ref 57693); Sat, 10 Sep 2022 08:43:01 +0000 Original-Received: (at 57693) by debbugs.gnu.org; 10 Sep 2022 08:42:59 +0000 Original-Received: from localhost ([127.0.0.1]:36552 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oWw4o-0004MN-P8 for submit@debbugs.gnu.org; Sat, 10 Sep 2022 04:42:59 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:43512) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oWw4n-0004MB-Ca for 57693@debbugs.gnu.org; Sat, 10 Sep 2022 04:42:57 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:54546) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oWw4i-0006nx-5m; Sat, 10 Sep 2022 04:42:52 -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=Zv3n2ISNWLzW2FU6AbmPWuX5BK9IDD35gt2yrK/W0lA=; b=HVGRPAr4ywsm LCL2tK68ts4O0N6dQ8IOtgNXTIL+wTB1RYkUPi40G5oD5xjfOOSVxyACFRxJbQ1IYqO/2lVDT38sk 4PSMhnPyNunxo9gbW307HoYO3xvCxGjC7F7OxNgsF4K7ceAuG59Khw1okzlKjLf9/rxsIZd5+TC0u Hw79s69WS7APcVlRNcSdkalv5039P+hkdH7vud1Es/2BmDX1I6A0S5GENzh8Xq+EMMtVQoeb2GPoz ceIWO9m66x3vXUncq/Q/psiaznIzNpdEq7BT1gKh4dx1188+I4IHP3U/yVZr3mB/Y/sAJeWuKlSfP aKzF/t8OlsQkIGIa361x/g==; Original-Received: from [87.69.77.57] (port=3526 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 1oWw4h-0000yq-L1; Sat, 10 Sep 2022 04:42:51 -0400 In-Reply-To: <87edwjy77h.fsf@localhost> (message from Ihor Radchenko on Sat, 10 Sep 2022 16:17:06 +0800) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:242090 Archived-At: > From: Ihor Radchenko > Cc: 57693@debbugs.gnu.org > Date: Sat, 10 Sep 2022 16:17:06 +0800 > > Eli Zaretskii writes: > > >> This should indeed be slightly more accurate. However, it will still not > >> cover scenarios when, for example, an overlay at point has 'face > >> property that sets a font that is unable to display given char. Or do I > >> miss something? > > > > Or what if the character has a display-table entry that calls for > > displaying a different codepoint? > > > > Such situations would require a very different test to be 100% > > accurate. > > Yup. And I am asking if there is such test exposed to Elisp. Display > code certainly knows when some character cannot be displayed and must be > replaced by its hex code. The display engine only knows it retroactively, when it tried and failed to display a character. > > For that reason, my suggestion would be to have the defcustom by > > default specify some safe value, and leave it to users to customize it > > to more fancy characters if they know it works in their > > configurations. Or just document that the default value may not > > produce the expected display in some rare situations, i.e. leave it to > > the users in such rare situations to customize back to a safe value. > > This is not great. I am really hoping that we can make nicer defaults > when possible and only fallback to something robust when fancy version > cannot be used. I'm not sure I understand how this could be done even in principle. The conditions and restrictions you put forward can only be tested by trying to display the character at its specific place in a specific buffer and a specific window (because all of those can potentially affect the face and thus the font). We can code a function that emulates the display, but such a function can only work if the offending character was already inserted into its place and is part of buffer text. Is this something you'd consider good enough, to have to do something like insert the character call the new magic if the new magic says NO-CAN-DO replace the character with something else If the above is acceptable, I think it can be done, although it would not be very useful in other situations. But if you want to know the answer before you insert the character, I don't think we know how to satisfy your requirements with 100% accuracy. At least I cannot see how it could be done; maybe someone else will.