bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#57693: 29.0.50; Is there a more reliable version of `char-displayabl


From: Eli Zaretskii
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

> 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 via email to

[Prev in Thread] Current Thread [Next in Thread]