bug#57693: 29.0.50; Is there a more reliable version of `char-displayable-p'?

bug#57693: 29.0.50; Is there a more reliable version of `char-displayable-p'?

[Ihor Radchenko]

Hello,

In Org, we have recently had a need to check if a Unicode character can
be displayed in buffer.

We used the following:
(...
  (if (and (display-graphic-p)
           (char-displayable-p ?⭠)
           (char-displayable-p ?─))
      "⭠ now ───────────────────────────────────────────────"
    "now - - - - - - - - - - - - - - - - - - - - - - - - -")
...)

However, char-displayable-p returned false-positive for one user:
https://list.orgmode.org/orgmode/87mtddhprr.fsf@localhost/ 

False-positives are indeed not unexpected in char-displayable-p; just as
its docstring warns. However, I am now wondering if there is some more
accurate way to know if a character can be actually displayed on buffer
or not.

-- 
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92

bug#57693: 29.0.50; Is there a more reliable version of `char-displayable-p'?

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@gmail.com>
> Date: Fri, 09 Sep 2022 21:25:35 +0800
> 
> In Org, we have recently had a need to check if a Unicode character can
> be displayed in buffer.
> 
> We used the following:
> (...
>   (if (and (display-graphic-p)
>            (char-displayable-p ?⭠)
>            (char-displayable-p ?─))
>       "⭠ now ───────────────────────────────────────────────"
>     "now - - - - - - - - - - - - - - - - - - - - - - - - -")
> ...)
> 
> However, char-displayable-p returned false-positive for one user:
> https://list.orgmode.org/orgmode/87mtddhprr.fsf@localhost/ 
> 
> False-positives are indeed not unexpected in char-displayable-p; just as
> its docstring warns. However, I am now wondering if there is some more
> accurate way to know if a character can be actually displayed on buffer
> or not.

I'd need to know more details.  Why did this test fail for that user?

Also, what exactly does the test above intend to test?  Are you
interested in whether this character can be displayed at all,
regardless of which font is to be used, or do you want it to be
displayed with the default face's font?

To answer your question: the most accurate way is to actually try
displaying the character and see if that works.  Not sure if it helps
you, though especially since that code is in a defcustom, AFAIU.

bug#57693: 29.0.50; Is there a more reliable version of `char-displayable-p'?

[Robert Pluim]

>>>>> On Fri, 09 Sep 2022 21:25:35 +0800, Ihor Radchenko <yantar92@gmail.com> said:

    Ihor> Hello,
    Ihor> In Org, we have recently had a need to check if a Unicode character can
    Ihor> be displayed in buffer.

    Ihor> We used the following:
    Ihor> (...
    Ihor>   (if (and (display-graphic-p)
    Ihor>            (char-displayable-p ?⭠)
    Ihor>            (char-displayable-p ?─))
    Ihor>       "⭠ now ───────────────────────────────────────────────"
    Ihor>     "now - - - - - - - - - - - - - - - - - - - - - - - - -")
    Ihor> ...)

    Ihor> However, char-displayable-p returned false-positive for one user:
    Ihor> https://list.orgmode.org/orgmode/87mtddhprr.fsf@localhost/ 

    Ihor> False-positives are indeed not unexpected in char-displayable-p; just as
    Ihor> its docstring warns. However, I am now wondering if there is some more
    Ihor> accurate way to know if a character can be actually displayed on buffer
    Ihor> or not.

Iʼd look at the guts of `describe-char-display' in
"lisp/descr-text.el" for inspiration (or even use it as is). It takes
a `pos' argument so you may have to wrap it in `with-temp-buffer' +
`insert'.

Robert
-- 

bug#57693: 29.0.50; Is there a more reliable version of `char-displayable-p'?

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> I'd need to know more details.  Why did this test fail for that user?

You can find the details here:
https://lists.gnu.org/r/emacs-orgmode/2022-07/msg00402.html

Alternative link to the same thread:
https://list.orgmode.org/27918f90-4a82-9f70-611e-7fc5475e2e60@oracle.com/

> Also, what exactly does the test above intend to test?  Are you
> interested in whether this character can be displayed at all,
> regardless of which font is to be used, or do you want it to be
> displayed with the default face's font?

The purpose of the test is to figure out if we should use the pretty
UTF-8 characters or if we should use the less pretty ASCII ones.

The result is then used in the org agenda buffer.  So it had better
display, basically.  The problem is that some users saw that they got
the UTF-8 characters with the above code, but they displayed as the
"hex-squares" (I forget the official name).

> To answer your question: the most accurate way is to actually try
> displaying the character and see if that works.  Not sure if it helps
> you, though especially since that code is in a defcustom, AFAIU.

That doesn't help here, unfortunately.  :-(

We would need a way to figure this out programmatically.  (It's in a
defcustom, yes.)

bug#57693: 29.0.50; Is there a more reliable version of `char-displayable-p'?

[Stefan Kangas]

Robert Pluim <rpluim@gmail.com> writes:

>     Ihor> False-positives are indeed not unexpected in char-displayable-p; just as
>     Ihor> its docstring warns. However, I am now wondering if there is some more
>     Ihor> accurate way to know if a character can be actually displayed on buffer
>     Ihor> or not.
>
> Iʼd look at the guts of `describe-char-display' in
> "lisp/descr-text.el" for inspiration (or even use it as is). It takes
> a `pos' argument so you may have to wrap it in `with-temp-buffer' +
> `insert'.

I know very little about this area of Emacs, but is there any reason why
we couldn't just (try to) make `char-displayable-p' more accurate?

I'm not asking for a perfect solution, but even just making it a bit
better might be a step forward.

bug#57693: 29.0.50; Is there a more reliable version of `char-displayable-p'?

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

> Also, what exactly does the test above intend to test?  Are you
> interested in whether this character can be displayed at all,
> regardless of which font is to be used, or do you want it to be
> displayed with the default face's font?
>
> To answer your question: the most accurate way is to actually try
> displaying the character and see if that works.  Not sure if it helps
> you, though especially since that code is in a defcustom, AFAIU.

Makes sense. Trying to determine if a character can be displayed
a-priori in defcustom was just the "easy" approach.

It makes sense that we must try to insert the character first in order
to know if it can be displayed. At least, individual buffers may have
buffer-local face-remapping-alist that may completely change the
display.

However, it is not very clear for me how to determine programmatically if
given character is displayable in buffer.

-- 
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92

bug#57693: 29.0.50; Is there a more reliable version of `char-displayable-p'?

[Ihor Radchenko]

Robert Pluim <rpluim@gmail.com> writes:

> Iʼd look at the guts of `describe-char-display' in
> "lisp/descr-text.el" for inspiration (or even use it as is). It takes
> a `pos' argument so you may have to wrap it in `with-temp-buffer' +
> `insert'.

`with-temp-buffer' is not a good option because it may have different
buffer-local environment compared to the actual buffer.

As for `describe-char-display', do you refer to `internal-char-font'?
`internal-char-font' is "For internal use only." though. Or can we get
something out of the `describe-char-display' return value? This function
does not have a docstring, and it is not very clear what the possible
return values can be and which return values are indicative of
non-displayable characters.

-- 
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92

bug#57693: 29.0.50; Is there a more reliable version of `char-displayable-p'?

[Ihor Radchenko]

Stefan Kangas <stefankangas@gmail.com> writes:

> I know very little about this area of Emacs, but is there any reason why
> we couldn't just (try to) make `char-displayable-p' more accurate?
>
> I'm not asking for a perfect solution, but even just making it a bit
> better might be a step forward.

From the docstring:

>> On a multi-font display, the test is only whether there is an
>> appropriate font from the selected frame's fontset to display
>> CHAR's charset in general.  Since fonts may be specified on a
>> per-character basis, this may not be accurate.

The actual font used to display char in specific buffer at specific
position may depend on various buffer-local settings, property
inheritance, and fontification (possibly modified by user). As Eli
pointed, the most accurate way to check if character can be displayed
involves trying to insert it first, letting the display engine do its
job, and checking what is the result.

-- 
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92

bug#57693: 29.0.50; Is there a more reliable version of `char-displayable-p'?

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Fri, 9 Sep 2022 18:25:27 -0400
> Cc: 57693@debbugs.gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I'd need to know more details.  Why did this test fail for that user?
> 
> You can find the details here:
> https://lists.gnu.org/r/emacs-orgmode/2022-07/msg00402.html

I'm probably missing something, because I didn't see there an
explanation of the problem I was looking for.

The problem which AFAIU Ihor raised was that char-displayable-p
returns non-nil, when the character actually cannot be displayed.
This is what I'm asking: how come char-displayable-p thought it could
find a font for the character, when Emacs failed to find the font when
it was time to actually display that character?

Ihor says that the reason could be some buffer-specific settings that
char-displayable-p didn't take into consideration.  If that's the
reason, could someone tell what those settings were in this case?

bug#57693: 29.0.50; Is there a more reliable version of `char-displayable-p'?

[Eli Zaretskii]

> Cc: 57693@debbugs.gnu.org
> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Fri, 9 Sep 2022 18:25:53 -0400
> 
> Robert Pluim <rpluim@gmail.com> writes:
> 
> >     Ihor> False-positives are indeed not unexpected in char-displayable-p; just as
> >     Ihor> its docstring warns. However, I am now wondering if there is some more
> >     Ihor> accurate way to know if a character can be actually displayed on buffer
> >     Ihor> or not.
> >
> > Iʼd look at the guts of `describe-char-display' in
> > "lisp/descr-text.el" for inspiration (or even use it as is). It takes
> > a `pos' argument so you may have to wrap it in `with-temp-buffer' +
> > `insert'.
> 
> I know very little about this area of Emacs, but is there any reason why
> we couldn't just (try to) make `char-displayable-p' more accurate?

From where I stand, it already is, for GUI frames.  If we discovered
some deficiency in what it does, we need to understand the deficiency
and try to remove it.

bug#57693: 29.0.50; Is there a more reliable version of `char-displayable-p'?

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

> The problem which AFAIU Ihor raised was that char-displayable-p
> returns non-nil, when the character actually cannot be displayed.
> This is what I'm asking: how come char-displayable-p thought it could
> find a font for the character, when Emacs failed to find the font when
> it was time to actually display that character?
>
> Ihor says that the reason could be some buffer-specific settings that
> char-displayable-p didn't take into consideration.  If that's the
> reason, could someone tell what those settings were in this case?

The author of the linked bug report solved the problem by installing
some extra font. So, it was likely not a question of buffer-specific
settings in that particular case.

-- 
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92

bug#57693: 29.0.50; Is there a more reliable version of `char-displayable-p'?

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@gmail.com>
> Cc: 57693@debbugs.gnu.org
> Date: Sat, 10 Sep 2022 12:48:07 +0800
> 
> At least, individual buffers may have buffer-local
> face-remapping-alist that may completely change the display.

Is this what happened in the case of that user where
char-displayable-p failed to detect that the character cannot be
displayed?

> However, it is not very clear for me how to determine programmatically if
> given character is displayable in buffer.

Make the char-displayable-p test at run time, I guess, i.e. when you
are actually about to insert it.

bug#57693: 29.0.50; Is there a more reliable version of `char-displayable-p'?

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@gmail.com>
> Cc: Stefan Kangas <stefankangas@gmail.com>,  57693@debbugs.gnu.org
> Date: Sat, 10 Sep 2022 14:06:16 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > The problem which AFAIU Ihor raised was that char-displayable-p
> > returns non-nil, when the character actually cannot be displayed.
> > This is what I'm asking: how come char-displayable-p thought it could
> > find a font for the character, when Emacs failed to find the font when
> > it was time to actually display that character?
> >
> > Ihor says that the reason could be some buffer-specific settings that
> > char-displayable-p didn't take into consideration.  If that's the
> > reason, could someone tell what those settings were in this case?
> 
> The author of the linked bug report solved the problem by installing
> some extra font. So, it was likely not a question of buffer-specific
> settings in that particular case.

Does it mean we don't understand why there was a failure in that case?
It is imperative that we do understand it, to see whether
char-displayable-p could be improved not to fail in those cases.

bug#57693: 29.0.50; Is there a more reliable version of `char-displayable-p'?

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

>> However, it is not very clear for me how to determine programmatically if
>> given character is displayable in buffer.
>
> Make the char-displayable-p test at run time, I guess, i.e. when you
> are actually about to insert it.

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?

-- 
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92

bug#57693: 29.0.50; Is there a more reliable version of `char-displayable-p'?

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

>> The author of the linked bug report solved the problem by installing
>> some extra font. So, it was likely not a question of buffer-specific
>> settings in that particular case.
>
> Does it mean we don't understand why there was a failure in that case?
> It is imperative that we do understand it, to see whether
> char-displayable-p could be improved not to fail in those cases.

Unfortunately, no further details have been given.
I explicitly asked to share more details, but the user was uninterested
to dig further. See https://list.orgmode.org/orgmode/233fa8fb-e2a3-a121-5d9e-56de9a7ebfc5@oracle.com/

I am unable to reproduce the problem in my system. Maybe someone with
limited fontset can try to recreate the problem.

-- 
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92

bug#57693: 29.0.50; Is there a more reliable version of `char-displayable-p'?

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@gmail.com>
> Cc: 57693@debbugs.gnu.org
> Date: Sat, 10 Sep 2022 14:37:41 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> However, it is not very clear for me how to determine programmatically if
> >> given character is displayable in buffer.
> >
> > Make the char-displayable-p test at run time, I guess, i.e. when you
> > are actually about to insert it.
> 
> 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.

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.

bug#57693: 29.0.50; Is there a more reliable version of `char-displayable-p'?

[Ihor Radchenko]

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.

> 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 was hoping that Org can do the following:
1. Allow org-agenda-current-time-string to be a list of ("fancy string"
 "fallback")
2. When actually inserting org-agenda-current-time-string to buffer,
test if "fancy string" can be displayed and if not insert the
"fallback".

The only question is how to test whether all the chars in the inserted
string are displayed.

-- 
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92

bug#57693: 29.0.50; Is there a more reliable version of `char-displayable-p'?

[Eli Zaretskii]

> 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.

bug#57693: 29.0.50; Is there a more reliable version of `char-displayable-p'?

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

>> 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.

The situation is similar to `string-pixel-width'.
Trying to display and checking retroactively should be a valid option,
unless I miss something.

>> 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.

The described approach should be acceptable.
What I have in mind is a function like

  (insert-displayable '("fancy version" "backup"))

The function will try to insert "fancy version" first; check if all the
characters are displayable, and replace the inserted text with "backup"
if not.

-- 
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92

bug#57693: 29.0.50; Is there a more reliable version of `char-displayable-p'?

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@gmail.com>
> Cc: 57693@debbugs.gnu.org
> Date: Sun, 11 Sep 2022 17:31:06 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> 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.
> 
> The situation is similar to `string-pixel-width'.

??? You rejected such methods in an earlier message, because it
required a temporary buffer, which you said will not reproduce the
exact environment of the buffer where you want to show the character.
Or what am I missing?

> >   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.
> 
> The described approach should be acceptable.
> What I have in mind is a function like
> 
>   (insert-displayable '("fancy version" "backup"))
> 
> The function will try to insert "fancy version" first; check if all the
> characters are displayable, and replace the inserted text with "backup"
> if not.

OK, I will see what I can do.

bug#57693: 29.0.50; Is there a more reliable version of `char-displayable-p'?

[Eli Zaretskii]

> Cc: 57693@debbugs.gnu.org
> Date: Sun, 11 Sep 2022 12:43:52 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> 
> > From: Ihor Radchenko <yantar92@gmail.com>
> > Cc: 57693@debbugs.gnu.org
> > Date: Sun, 11 Sep 2022 17:31:06 +0800
> > 
> > >   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.
> > 
> > The described approach should be acceptable.
> > What I have in mind is a function like
> > 
> >   (insert-displayable '("fancy version" "backup"))
> > 
> > The function will try to insert "fancy version" first; check if all the
> > characters are displayable, and replace the inserted text with "backup"
> > if not.
> 
> OK, I will see what I can do.

Here's what I suggest for GUI frames:

  (defun insert-char-safely (ch repl)
    "Insert character CH, if it can be displayed; otherwise insert REPL."
    (insert ch)
    (unless (font-at (1- (point)))
      (delete-char -1)
      (insert repl)))

Do you need this to work for TTY frames as well?  If so, it could be a
problem, since most terminal emulators don't provide a way of
inquiring whether a certain character can be displayed.
char-displayable-p currently just checks on most terminals that the
terminal-coding-system can _encode_ the character, which isn't enough
if the terminal encoding is UTF-8.

bug#57693: 29.0.50; Is there a more reliable version of `char-displayable-p'?

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

>> > The display engine only knows it retroactively, when it tried and
>> > failed to display a character.
>> 
>> The situation is similar to `string-pixel-width'.
>
> ??? You rejected such methods in an earlier message, because it
> required a temporary buffer, which you said will not reproduce the
> exact environment of the buffer where you want to show the character.
> Or what am I missing?

Sorry for not being clear.

I was referring to the approach when we try to insert a text into buffer
(temporary or not) and then check the result in some way.

-- 
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92

bug#57693: 29.0.50; Is there a more reliable version of `char-displayable-p'?

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

> Here's what I suggest for GUI frames:
>
>   (defun insert-char-safely (ch repl)
>     "Insert character CH, if it can be displayed; otherwise insert REPL."
>     (insert ch)
>     (unless (font-at (1- (point)))
>       (delete-char -1)
>       (insert repl)))

Thanks!

> Do you need this to work for TTY frames as well?  If so, it could be a
> problem, since most terminal emulators don't provide a way of
> inquiring whether a certain character can be displayed.
> char-displayable-p currently just checks on most terminals that the
> terminal-coding-system can _encode_ the character, which isn't enough
> if the terminal encoding is UTF-8.

The original code I was referring to unconditionally used a "safe"
fallback on terminals. If there is no technical possibility to determine
whether a character can be displayed, so be it.

I am thinking about something like below (to insert string, not a char),

(defun org-insert-displayable (&rest strings)
  "Insert the first displayable string from STRINGS.
If none of the STRINGS can be displayed, display the last string.
In terminal, always insert the last string."
  (if (not (display-graphic-p))
      (insert (car (last strings)))
    (catch :displayable
      (dolist (string strings)
	(insert string)
        (save-excursion
          (catch :undisplayable
            (dotimes (i (length string))
              (unless (font-at (- (point) i 1))
		(throw :undisplayable t)))
            ;; All chars can be displayed. Keep the inserted string.
            (throw :displayable t)))
        ;; Some char cannot be displayed. Clear the insertion and move ahead to
        ;; the next candidate.
        (delete-char (- (length string))))
      ;; None displayable.
      (insert (car (last strings))))))

-- 
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92

bug#57693: 29.0.50; Is there a more reliable version of `char-displayable-p'?

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@gmail.com>
> Cc: 57693@debbugs.gnu.org
> Date: Mon, 12 Sep 2022 13:46:50 +0800
> 
> > Do you need this to work for TTY frames as well?  If so, it could be a
> > problem, since most terminal emulators don't provide a way of
> > inquiring whether a certain character can be displayed.
> > char-displayable-p currently just checks on most terminals that the
> > terminal-coding-system can _encode_ the character, which isn't enough
> > if the terminal encoding is UTF-8.
> 
> The original code I was referring to unconditionally used a "safe"
> fallback on terminals. If there is no technical possibility to determine
> whether a character can be displayed, so be it.

If the terminal's encoding is UTF-8, and it doesn't support the method
we use to query about individual glyphs, char-displayable-p may return
non-nil when the character cannot be displayed, i.e. will show as an
empty box or something.  Otherwise, char-displayable-p does provide
the correct answer for TTY frames.

> I am thinking about something like below (to insert string, not a char),

LGTM.

bug#57693: 29.0.50; Is there a more reliable version of `char-displayable-p'?

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

> If the terminal's encoding is UTF-8, and it doesn't support the method
> we use to query about individual glyphs, char-displayable-p may return
> non-nil when the character cannot be displayed, i.e. will show as an
> empty box or something.  Otherwise, char-displayable-p does provide
> the correct answer for TTY frames.

Do I understand correctly that:
1. `font-at' is not sufficient for terminals, and we also need to use
   `char-displayable-p'
2. `char-displayable-p' works on many terminals but may be inaccurate in some

-- 
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92

bug#57693: 29.0.50; Is there a more reliable version of `char-displayable-p'?

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@gmail.com>
> Cc: 57693@debbugs.gnu.org
> Date: Tue, 13 Sep 2022 09:44:06 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > If the terminal's encoding is UTF-8, and it doesn't support the method
> > we use to query about individual glyphs, char-displayable-p may return
> > non-nil when the character cannot be displayed, i.e. will show as an
> > empty box or something.  Otherwise, char-displayable-p does provide
> > the correct answer for TTY frames.
> 
> Do I understand correctly that:
> 1. `font-at' is not sufficient for terminals, and we also need to use
>    `char-displayable-p'
> 2. `char-displayable-p' works on many terminals but may be inaccurate in some

More or less.  More accurately:

 . font-at is not useful on text-mode frames
 . char-displayable-p, when invoked on text-mode frames, in most cases
   reports only whether the character can be safely encoded by
   terminal-coding-system
 . if terminal-coding-system is UTF-8, char-displayable-p will
   generally trivially return non-nil, unless the terminal supports
   queries about glyphs that it has for specific characters
 . the only terminal I know of that supports the above queries is the
   Linux console, which I think is not very popular among Emacs users
 . for terminals that do support such queries, you can use this:

      (internal-char-font nil CHAR)

   which will return a positive number if CHAR can be displayed,
   negative number if it cannot, or nil if the query is not supported.

So an efficient method of testing this for terminal would be:

  . if terminal-coding-system is UTF-8, call internal-char-font to see
    if the character is supported, and if it returns a number,
    consider the character supported if the number is positive, not
    supported otherwise
  . otherwise, if terminal-coding-system is UTF-8, consider character
    supported (and pray)
  . otherwise call char-displayable-p and judge by its value

This is more efficient than calling char-displayable-p because I
expect most terminals these days to use UTF-8 encoding, and for them
the above is optimized.

bug#57693: 29.0.50; Is there a more reliable version of `char-displayable-p'?

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

> So an efficient method of testing this for terminal would be:
>
>   . if terminal-coding-system is UTF-8, call internal-char-font to see

On my side, (terminal-coding-system) returns 'utf-8-unix
However, I imagine that other utf-8 variants may be returned, say, on
Windows.

Is there some standard way to know is a coding system is utf-8 or not?

-- 
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92

bug#57693: 29.0.50; Is there a more reliable version of `char-displayable-p'?

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@gmail.com>
> Cc: 57693@debbugs.gnu.org
> Date: Wed, 14 Sep 2022 09:52:59 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > So an efficient method of testing this for terminal would be:
> >
> >   . if terminal-coding-system is UTF-8, call internal-char-font to see
> 
> On my side, (terminal-coding-system) returns 'utf-8-unix
> However, I imagine that other utf-8 variants may be returned, say, on
> Windows.
> 
> Is there some standard way to know is a coding system is utf-8 or not?

Yes, use coding-system-base.

bug#57693: 29.0.50; Is there a more reliable version of `char-displayable-p'?

[Stefan Kangas]

Ihor Radchenko <yantar92@gmail.com> writes:

> I am thinking about something like below (to insert string, not a char),
>
> (defun org-insert-displayable (&rest strings)
[snip]

Should we put something like this in subr.el or perhaps subr-x.el?

I can see a need for it in many more places.  For example, I'm looking
into improving the header-line-format in calc-mode with some Unicode
characters instead of a simple en dash (i.e. "‒" instead of "-").

bug#57693: 29.0.50; Is there a more reliable version of `char-displayable-p'?

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Fri, 17 Feb 2023 11:18:45 -0800
> Cc: 57693@debbugs.gnu.org
> 
> Ihor Radchenko <yantar92@gmail.com> writes:
> 
> > I am thinking about something like below (to insert string, not a char),
> >
> > (defun org-insert-displayable (&rest strings)
> [snip]
> 
> Should we put something like this in subr.el or perhaps subr-x.el?

Something like what?  If you want to suggest some specific function,
please show the proposed code, and let's take it from there.
Otherwise, this bug discussion was long and considered several issues,
and it is hard to know what you have in mind.

> I can see a need for it in many more places.  For example, I'm looking
> into improving the header-line-format in calc-mode with some Unicode
> characters instead of a simple en dash (i.e. "‒" instead of "-").

And what is the problem with using char-displayable-p in that case?

bug#57693: 29.0.50; Is there a more reliable version of `char-displayable-p'?

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> Something like what?  If you want to suggest some specific function,
> please show the proposed code, and let's take it from there.
> Otherwise, this bug discussion was long and considered several issues,
> and it is hard to know what you have in mind.

The code is here:

    https://debbugs.gnu.org/cgi/bugreport.cgi?bug=57693#71

>> I can see a need for it in many more places.  For example, I'm looking
>> into improving the header-line-format in calc-mode with some Unicode
>> characters instead of a simple en dash (i.e. "‒" instead of "-").
>
> And what is the problem with using char-displayable-p in that case?

My concern is that `char-displayable-p' will return t even if the
character is not displayable.

bug#57693: 29.0.50; Is there a more reliable version of `char-displayable-p'?

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Fri, 17 Feb 2023 14:31:49 -0800
> Cc: yantar92@gmail.com, 57693@debbugs.gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Something like what?  If you want to suggest some specific function,
> > please show the proposed code, and let's take it from there.
> > Otherwise, this bug discussion was long and considered several issues,
> > and it is hard to know what you have in mind.
> 
> The code is here:
> 
>     https://debbugs.gnu.org/cgi/bugreport.cgi?bug=57693#71

That's for GUI displays only.  And it's for strings, not characters.
To test a single character, you don't need a separate function, IMO,
you just need to use the test that is the core of that code.

> > And what is the problem with using char-displayable-p in that case?
> 
> My concern is that `char-displayable-p' will return t even if the
> character is not displayable.

If you need to care for TTY frames, that problem has no known solution
that works for all terminal emulators.  So using fancy characters in
general-purpose Emacs features is a problem that cannot be solved
programmatically, or at least we don't currently know how to do that.

bug#57693: 29.0.50; Is there a more reliable version of `char-displayable-p'?

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> That's for GUI displays only.  And it's for strings, not characters.
> To test a single character, you don't need a separate function, IMO,
> you just need to use the test that is the core of that code.
[...]
> If you need to care for TTY frames, that problem has no known solution
> that works for all terminal emulators.  So using fancy characters in
> general-purpose Emacs features is a problem that cannot be solved
> programmatically, or at least we don't currently know how to do that.

Thanks, those are useful clarifications.  But could we not just fall
back to the replacement on TTY frames instead?  Something like:

    (defun insert-char-safely (ch repl)
      "Insert character CH, if it can be displayed; otherwise insert REPL.
    On TTY frames, always insert REPL."
      (if (not (display-graphic-p))
          (insert repl)
        (insert ch)
        (unless (font-at (1- (point)))
          (delete-char -1)
          (insert repl))))

bug#57693: 29.0.50; Is there a more reliable version of `char-displayable-p'?

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Sat, 18 Feb 2023 01:00:38 -0800
> Cc: yantar92@gmail.com, 57693@debbugs.gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > That's for GUI displays only.  And it's for strings, not characters.
> > To test a single character, you don't need a separate function, IMO,
> > you just need to use the test that is the core of that code.
> [...]
> > If you need to care for TTY frames, that problem has no known solution
> > that works for all terminal emulators.  So using fancy characters in
> > general-purpose Emacs features is a problem that cannot be solved
> > programmatically, or at least we don't currently know how to do that.
> 
> Thanks, those are useful clarifications.  But could we not just fall
> back to the replacement on TTY frames instead?  Something like:
> 
>     (defun insert-char-safely (ch repl)
>       "Insert character CH, if it can be displayed; otherwise insert REPL.
>     On TTY frames, always insert REPL."
>       (if (not (display-graphic-p))
>           (insert repl)
>         (insert ch)
>         (unless (font-at (1- (point)))
>           (delete-char -1)
>           (insert repl))))

We could, but IME typical uses of fancy characters do not insert them
into a buffer, but use them in header-line, overlay strings, and
suchlikes.

bug#57693: 29.0.50; Is there a more reliable version of `char-displayable-p'?

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

>>     (defun insert-char-safely (ch repl)
>>       "Insert character CH, if it can be displayed; otherwise insert REPL.
>>     On TTY frames, always insert REPL."
>>       (if (not (display-graphic-p))
>>           (insert repl)
>>         (insert ch)
>>         (unless (font-at (1- (point)))
>>           (delete-char -1)
>>           (insert repl))))
>
> We could, but IME typical uses of fancy characters do not insert them
> into a buffer, but use them in header-line, overlay strings, and
> suchlikes.

`font-at' accepts optional third argument STRING.
For example, (font-at 0 nil "🧠a")

I am not sure how reliable this approach with string is though.

As an alternative thought, may Emacs display engine accept a text
property like 'display-alternative to display some fallback
character/string if some parts of the displayed text cannot be
displayed?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

bug#57693: 29.0.50; Is there a more reliable version of `char-displayable-p'?

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

> If you need to care for TTY frames, that problem has no known solution
> that works for all terminal emulators.  So using fancy characters in
> general-purpose Emacs features is a problem that cannot be solved
> programmatically, or at least we don't currently know how to do that.

I am not sure if it is relevant, but I see
https://unix.stackexchange.com/questions/184345/detect-how-much-of-unicode-my-terminal-supports-even-through-screen

May it be something of use for Emacs?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

bug#57693: 29.0.50; Is there a more reliable version of `char-displayable-p'?

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: Stefan Kangas <stefankangas@gmail.com>, yantar92@gmail.com,
>  57693@debbugs.gnu.org
> Date: Sat, 18 Feb 2023 11:32:56 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >>     (defun insert-char-safely (ch repl)
> >>       "Insert character CH, if it can be displayed; otherwise insert REPL.
> >>     On TTY frames, always insert REPL."
> >>       (if (not (display-graphic-p))
> >>           (insert repl)
> >>         (insert ch)
> >>         (unless (font-at (1- (point)))
> >>           (delete-char -1)
> >>           (insert repl))))
> >
> > We could, but IME typical uses of fancy characters do not insert them
> > into a buffer, but use them in header-line, overlay strings, and
> > suchlikes.
> 
> `font-at' accepts optional third argument STRING.
> For example, (font-at 0 nil "🧠a")

My comment was because Stefan suggested a function that inserts a
character into a buffer, not because font-at by default reports about
a character at point.

> As an alternative thought, may Emacs display engine accept a text
> property like 'display-alternative to display some fallback
> character/string if some parts of the displayed text cannot be
> displayed?

We already have something like that: see glyphless-char-display and
glyphless-char-display-mode.  The problem is that (a) on GUI displays
the replacement will be displayed in a box; (b) the replacement must
be an ASCII character; and (c) the char-table we use for that is
global, i.e. it affects the entire session.  But if someone wants a
more flexible feature which lifts some of those restrictions, that's
the place to start nonetheless.

bug#57693: 29.0.50; Is there a more reliable version of `char-displayable-p'?

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: Stefan Kangas <stefankangas@gmail.com>, yantar92@gmail.com,
>  57693@debbugs.gnu.org
> Date: Sat, 18 Feb 2023 11:35:33 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > If you need to care for TTY frames, that problem has no known solution
> > that works for all terminal emulators.  So using fancy characters in
> > general-purpose Emacs features is a problem that cannot be solved
> > programmatically, or at least we don't currently know how to do that.
> 
> I am not sure if it is relevant, but I see
> https://unix.stackexchange.com/questions/184345/detect-how-much-of-unicode-my-terminal-supports-even-through-screen
> 
> May it be something of use for Emacs?

If you are asking about the Linux console, then we already have a way
of asking it whether it supports a given character.

If you are asking about the kludges they suggest for other terminals,
where we are supposed to deduce support fro a character by counting
columns, then that is both unreliable and extremely cumbersome (we'd
need to try to actually display a character in order to know whether
its displayable).

bug#57693: 29.0.50; Is there a more reliable version of `char-displayable-p'?

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

> We already have something like that: see glyphless-char-display and
> glyphless-char-display-mode.

Thanks for the pointer! This sounds like a suitable approach when
displaying "fancy" characters.

> The problem is that (a) on GUI displays
> the replacement will be displayed in a box; (b) the replacement must
> be an ASCII character; and (c) the char-table we use for that is
> global, i.e. it affects the entire session.  But if someone wants a
> more flexible feature which lifts some of those restrictions, that's
> the place to start nonetheless.

What about

1. Allowing the char-table to be buffer-local or within text-properties
2. Making (set-char-table-range glyphless-char-display ?A ?B) work on
   GUI as well, not just in terminals
3. Making the rules recursive.
   So that setting something like
   (set-char-table-range glyphless-char-display ?A "1")
   (set-char-table-range glyphless-char-display ?1 "2")
   will display "A" as "2" (A->1->2)

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

bug#57693: 29.0.50; Is there a more reliable version of `char-displayable-p'?

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: stefankangas@gmail.com, yantar92@gmail.com, 57693@debbugs.gnu.org
> Date: Sun, 19 Feb 2023 11:31:24 +0000
> 
> 1. Allowing the char-table to be buffer-local

Trivial (should be possible right now)

> or within text-properties

Only if really needed.  Adding a text property for this will
complicate the display code which handles this, so I'd rather we
didn't unless we have a _very_ good reason.  And I don't see such a
reason, since we are talking about characters that cannot be displayed
by any available font, something that is unlikely to be limited to
just a small region of text.

> 2. Making (set-char-table-range glyphless-char-display ?A ?B) work on
>    GUI as well, not just in terminals

You mean (set-char-table-range glyphless-char-display ?A "B"), I
presume (the value cannot be a character, only a string).

> 3. Making the rules recursive.

What for?  It's a very significant complication, and I cannot see the
purpose.  The string value _must_ use only ASCII characters, precisely
_because_ we want to be sure no recursion will be needed.

bug#57693: 29.0.50; Is there a more reliable version of `char-displayable-p'?

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

>> or within text-properties
>
> Only if really needed.  Adding a text property for this will
> complicate the display code which handles this, so I'd rather we
> didn't unless we have a _very_ good reason.  And I don't see such a
> reason, since we are talking about characters that cannot be displayed
> by any available font, something that is unlikely to be limited to
> just a small region of text.

The replacement may only make sense in particular context. For example,
mode line indicator for newlines can be ?: or ?\ or ?/. If we want to
display a more intuitive Unicode char like ?⏎ or ?‸, it does not make
sense to replace all the ?⏎ in buffer with ?:.

Of course, even just having (2) will be an improvement.

>> 2. Making (set-char-table-range glyphless-char-display ?A ?B) work on
>>    GUI as well, not just in terminals
>
> You mean (set-char-table-range glyphless-char-display ?A "B"), I
> presume (the value cannot be a character, only a string).

Yes.

>> 3. Making the rules recursive.
>
> What for?  It's a very significant complication, and I cannot see the
> purpose.  The string value _must_ use only ASCII characters, precisely
> _because_ we want to be sure no recursion will be needed.

Makes sense. I was thinking about multiple alternatives from more fancy
to less fancy down to fallback ASCII. This feature is of minor
importance.

BTW, if we need the replacement of character sequences, is
`composition-function-table' supposed to be used? It is not
well-described in the manual and I only know it from
https://www.masteringemacs.org/article/unicode-ligatures-color-emoji

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

bug#57693: 29.0.50; Is there a more reliable version of `char-displayable-p'?

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: stefankangas@gmail.com, yantar92@gmail.com, 57693@debbugs.gnu.org
> Date: Sun, 19 Feb 2023 12:08:48 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> or within text-properties
> >
> > Only if really needed.  Adding a text property for this will
> > complicate the display code which handles this, so I'd rather we
> > didn't unless we have a _very_ good reason.  And I don't see such a
> > reason, since we are talking about characters that cannot be displayed
> > by any available font, something that is unlikely to be limited to
> > just a small region of text.
> 
> The replacement may only make sense in particular context. For example,
> mode line indicator for newlines can be ?: or ?\ or ?/. If we want to
> display a more intuitive Unicode char like ?⏎ or ?‸, it does not make
> sense to replace all the ?⏎ in buffer with ?:.

We could have a special glyphless-char-display table for mode-line and
header-line.  Buffer-local values don't apply well to those anyway,
because they display strings, not buffer text.

bug#57693: 29.0.50; Is there a more reliable version of `char-displayable-p'?

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

> We could have a special glyphless-char-display table for mode-line and
> header-line.  Buffer-local values don't apply well to those anyway,
> because they display strings, not buffer text.

Then, also margins, tab-bar, and menu-bar? I feel that simply allowing
text properties will be less cumbersome from the point of view of API.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

bug#57693: 29.0.50; Is there a more reliable version of `char-displayable-p'?

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: stefankangas@gmail.com, yantar92@gmail.com, 57693@debbugs.gnu.org
> Date: Sun, 19 Feb 2023 14:19:58 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > We could have a special glyphless-char-display table for mode-line and
> > header-line.  Buffer-local values don't apply well to those anyway,
> > because they display strings, not buffer text.
> 
> Then, also margins, tab-bar, and menu-bar?

Margins show buffer text.  Tab bar does not belong to any buffer.
Menu bar is not relevant (and is displayed by toolkits in most builds
anyway).

> I feel that simply allowing text properties will be less cumbersome
> from the point of view of API.

Not from the POV of the implementation, though.