unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Ihor Radchenko <yantar92@gmail.com>
Cc: 57693@debbugs.gnu.org
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	[thread overview]
Message-ID: <831qsjboy0.fsf@gnu.org> (raw)
In-Reply-To: <87edwjy77h.fsf@localhost> (message from Ihor Radchenko on Sat, 10 Sep 2022 16:17:06 +0800)

> From: Ihor Radchenko <yantar92@gmail.com>
> Cc: 57693@debbugs.gnu.org
> Date: Sat, 10 Sep 2022 16:17:06 +0800
> 
> Eli Zaretskii <eliz@gnu.org> 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.





  reply	other threads:[~2022-09-10  8:42 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-09 13:25 bug#57693: 29.0.50; Is there a more reliable version of `char-displayable-p'? Ihor Radchenko
2022-09-09 13:38 ` Eli Zaretskii
2022-09-09 22:25   ` Stefan Kangas
2022-09-10  6:01     ` Eli Zaretskii
2022-09-10  6:06       ` Ihor Radchenko
2022-09-10  6:35         ` Eli Zaretskii
2022-09-10  6:44           ` Ihor Radchenko
2022-09-10  4:48   ` Ihor Radchenko
2022-09-10  6:24     ` Eli Zaretskii
2022-09-10  6:37       ` Ihor Radchenko
2022-09-10  7:56         ` Eli Zaretskii
2022-09-10  8:17           ` Ihor Radchenko
2022-09-10  8:42             ` Eli Zaretskii [this message]
2022-09-11  9:31               ` Ihor Radchenko
2022-09-11  9:43                 ` Eli Zaretskii
2022-09-11 10:07                   ` Eli Zaretskii
2022-09-12  5:46                     ` Ihor Radchenko
2022-09-12 11:15                       ` Eli Zaretskii
2022-09-13  1:44                         ` Ihor Radchenko
2022-09-13 11:19                           ` Eli Zaretskii
2022-09-14  1:52                             ` Ihor Radchenko
2022-09-14  2:43                               ` Eli Zaretskii
2023-02-17 19:18                       ` Stefan Kangas
2023-02-17 19:29                         ` Eli Zaretskii
2023-02-17 22:31                           ` Stefan Kangas
2023-02-18  6:56                             ` Eli Zaretskii
2023-02-18  9:00                               ` Stefan Kangas
2023-02-18  9:18                                 ` Eli Zaretskii
2023-02-18 11:32                                   ` Ihor Radchenko
2023-02-18 11:56                                     ` Eli Zaretskii
2023-02-19 11:31                                       ` Ihor Radchenko
2023-02-19 11:55                                         ` Eli Zaretskii
2023-02-19 12:08                                           ` Ihor Radchenko
2023-02-19 12:23                                             ` Eli Zaretskii
2023-02-19 14:19                                               ` Ihor Radchenko
2023-02-19 15:02                                                 ` Eli Zaretskii
2023-02-18 11:35                               ` Ihor Radchenko
2023-02-18 12:00                                 ` Eli Zaretskii
2022-09-12  5:24                   ` Ihor Radchenko
2022-09-09 13:46 ` Robert Pluim
2022-09-09 22:25   ` Stefan Kangas
2022-09-10  4:56     ` Ihor Radchenko
2022-09-10  6:02     ` Eli Zaretskii
2022-09-10  4:53   ` Ihor Radchenko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=831qsjboy0.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=57693@debbugs.gnu.org \
    --cc=yantar92@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).