bug#56691: outline-minor-mode displays navigation arrow buttons as emojis

bug#56691: outline-minor-mode displays navigation arrow buttons as emojis

[Paul W. Rankin via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Summary:

First discovered in the describe-bindings buffer (C-h b). Screenshot: 
http://0x0.st/ojN5.png

Buffers using outline-minor-mode will attempt to add navigation arrow 
buttons (i.e. show/hide) displaying emojis instead of arrows or text 
representation.

This occurs even when widget-image-enable => nil.

Appears to be introduced in commit 
3a855c5dac1b5cc42ee57cebed0323d591b54c68

Steps to reproduce:

1. $emacs -Q
2. C-h b

Expected results:

Buffer navigation arrows are arrows.

Actual results:

Buffer navigation arrows are emojis.

Notes for the committer:

Do not use emojis in software designed for adults; what you see as 
whimsical appears to others as childish and unprofessional. While I 
cannot speak for vision-impaired users, this also raises the issue of 
whether emojis appropriated for functional use create yet another 
difficulty for those requiring screen readers.

As always, if you wish to add a feature to Emacs (i.e. not fix a bug) -- 
do not make that new feature enabled by default! This is incredibly 
rude. Document the feature and allow others to make their own choices.

bug#56691: outline-minor-mode displays navigation arrow buttons as emojis

[Paul W. Rankin via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Further notes:

User option outline-minor-mode-use-buttons appears to have no effect.

bug#56691: outline-minor-mode displays navigation arrow buttons as emojis

[Paul W. Rankin via Bug reports for GNU Emacs, the Swiss army knife of text editors]

As a temporary workaround, I’m overriding outline--valid-emoji-p to be 
more respectful:

     (defun outline--valid-emoji-p (_)
       nil)

bug#56691: outline-minor-mode displays navigation arrow buttons as emojis

[Paul W. Rankin via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Correction to original commit: 57030b90d54af1a47508fca032da2634b8c26f4c

bug#56691: outline-minor-mode displays navigation arrow buttons as emojis

[Gregory Heytings]

[-- Attachment #1: Type: text/plain, Size: 74 bytes --]


(setq outline-minor-mode-buttons '(("▶" "▼" outline--valid-char-p)))

bug#56691: outline-minor-mode displays navigation arrow buttons as emojis

[Lars Ingebrigtsen]

Gregory Heytings <gregory@heytings.org> writes:

> (setq outline-minor-mode-buttons '(("▶" "▼" outline--valid-char-p)))

Yes, that's the way to alter the look of these buttons currently.
(There's work in progress to add a more general mechanism for this,
because we'll be adding more buttons here and there.)

bug#56691: outline-minor-mode displays navigation arrow buttons as emojis

[Eli Zaretskii]

> Date: Fri, 22 Jul 2022 15:00:27 +1000
> From:  "Paul W. Rankin" via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> User option outline-minor-mode-use-buttons appears to have no effect.

This is because describe-bindings overrides it:

	(when describe-bindings-outline
          (setq-local outline-regexp ".*:$")
          (setq-local outline-heading-end-regexp ":\n")
          (setq-local outline-level (lambda () 1))
          (setq-local outline-minor-mode-cycle t
                      outline-minor-mode-highlight t)
          (setq-local outline-minor-mode-use-buttons t)  <<<<<<<<<<<<<<
          (outline-minor-mode 1)

Which I think is a bad idea to do unconditionally.  At the very least,
describe-bindings-outline's default value should NOT override
outline-minor-mode-use-buttons, and it should have a non-default
optional value to override it for users who want that.

bug#56691: outline-minor-mode displays navigation arrow buttons as emojis

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Which I think is a bad idea to do unconditionally.  At the very least,
> describe-bindings-outline's default value should NOT override
> outline-minor-mode-use-buttons, and it should have a non-default
> optional value to override it for users who want that.

Usage of outline (and buttons) in these buffers is new in Emacs 29, so I
think the way it's currently set up makes the most sense.  That is, we
certainly don't want outline-minor-mode-use-buttons to default to t, but
we do want to have buttons in this case to be on by default.

bug#56691: outline-minor-mode displays navigation arrow buttons as emojis

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: "Paul W. Rankin" <hello@paulwrankin.com>,  56691@debbugs.gnu.org
> Date: Sat, 23 Jul 2022 08:35:22 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Which I think is a bad idea to do unconditionally.  At the very least,
> > describe-bindings-outline's default value should NOT override
> > outline-minor-mode-use-buttons, and it should have a non-default
> > optional value to override it for users who want that.
> 
> Usage of outline (and buttons) in these buffers is new in Emacs 29, so I
> think the way it's currently set up makes the most sense.  That is, we
> certainly don't want outline-minor-mode-use-buttons to default to t, but
> we do want to have buttons in this case to be on by default.

Overriding a user option in this way is not something we do, or should
do.  The user settings should be honored.

Why is it a problem not to override that option, when its default
value will cause the buttons to be shown in Help buffers?  Put it
another way: why should we consider Help buffers under Outline Minor
mode be any different from any other buffer under that mode?

bug#56691: outline-minor-mode displays navigation arrow buttons as emojis

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Why is it a problem not to override that option, when its default
> value will cause the buttons to be shown in Help buffers?

I don't follow -- the default value of outline-minor-mode-use-buttons is
nil, so there'd be no buttons in the *Help* buffer.

> Put it another way: why should we consider Help buffers under Outline
> Minor mode be any different from any other buffer under that mode?

Mainly because other modes that use the option are edit-oriented modes,
so there the buttons are pretty annoying.

bug#56691: outline-minor-mode displays navigation arrow buttons as emojis

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: hello@paulwrankin.com,  56691@debbugs.gnu.org
> Date: Sat, 23 Jul 2022 09:28:31 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Why is it a problem not to override that option, when its default
> > value will cause the buttons to be shown in Help buffers?
> 
> I don't follow -- the default value of outline-minor-mode-use-buttons is
> nil, so there'd be no buttons in the *Help* buffer.

Sorry, I was confused about the defaults.

> > Put it another way: why should we consider Help buffers under Outline
> > Minor mode be any different from any other buffer under that mode?
> 
> Mainly because other modes that use the option are edit-oriented modes,
> so there the buttons are pretty annoying.

Then how about the other suggestion I made: to add one more value to
outline-minor-mode-use-buttons, which will allow to differentiate
between editing and non-editing major modes?

bug#56691: outline-minor-mode displays navigation arrow buttons as emojis

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Then how about the other suggestion I made: to add one more value to
> outline-minor-mode-use-buttons, which will allow to differentiate
> between editing and non-editing major modes?

Sorry, I missed that.  I think that sounds like a good idea.  Perhaps we
could use that new buffer mode predicate machinery, and default to
buttons on in all buffers that inherit from special-mode?  That'd allow
people fine grained control if they want.

bug#56691: outline-minor-mode displays navigation arrow buttons as emojis

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: hello@paulwrankin.com,  56691@debbugs.gnu.org
> Date: Sat, 23 Jul 2022 09:41:07 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Then how about the other suggestion I made: to add one more value to
> > outline-minor-mode-use-buttons, which will allow to differentiate
> > between editing and non-editing major modes?
> 
> Sorry, I missed that.  I think that sounds like a good idea.  Perhaps we
> could use that new buffer mode predicate machinery, and default to
> buttons on in all buffers that inherit from special-mode?  That'd allow
> people fine grained control if they want.

Sounds good.  This would also allow users to control what happens in
each of these cases, right?

bug#56691: outline-minor-mode displays navigation arrow buttons as emojis

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Sounds good.  This would also allow users to control what happens in
> each of these cases, right?

Yup.

I sorta decided to rework how icon/button selection works at the same
time, so it'll take some more time to work out all the kinks in this
area.

bug#56691: outline-minor-mode displays navigation arrow buttons as emojis

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> I sorta decided to rework how icon/button selection works at the same
> time, so it'll take some more time to work out all the kinks in this
> area.

I've now done this.  And note that customizing the buttons has now
changed completely, see (emacs)Icons for details.

bug#56691: outline-minor-mode displays navigation arrow buttons as emojis

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: hello@paulwrankin.com,  56691@debbugs.gnu.org
> Date: Thu, 28 Jul 2022 14:37:17 +0200
> 
> Lars Ingebrigtsen <larsi@gnus.org> writes:
> 
> > I sorta decided to rework how icon/button selection works at the same
> > time, so it'll take some more time to work out all the kinks in this
> > area.
> 
> I've now done this.  And note that customizing the buttons has now
> changed completely, see (emacs)Icons for details.

Thanks.

The test for Emoji display is not accurate enough.  Maybe we should
have a display-color-emoji-p predicate?  I added a FIXME there.

bug#56691: outline-minor-mode displays navigation arrow buttons as emojis

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> The test for Emoji display is not accurate enough.  Maybe we should
> have a display-color-emoji-p predicate?  I added a FIXME there.

Sounds like a good idea.  What would that predicate look like?

bug#56691: outline-minor-mode displays navigation arrow buttons as emojis

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: hello@paulwrankin.com,  56691@debbugs.gnu.org
> Date: Fri, 29 Jul 2022 13:32:57 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > The test for Emoji display is not accurate enough.  Maybe we should
> > have a display-color-emoji-p predicate?  I added a FIXME there.
> 
> Sounds like a good idea.  What would that predicate look like?

I think we can currently only do that by looking at the details of the
build.  Currently, color Emoji are supported only by builds with Cairo
and HarfBuzz on Unix and by macOS builds.

But even that could be not enough, since the necessary font may not be
installed.  So here's another idea: use font-at to check that it
returns one of the known color Emoji fonts for an Emoji character.
For example:

  (font-get (font-at 0 nil "😄") :family)
   => Symbola

We can then compare the value with a list of known families of fonts
that support color Emoji.  The downside of this is that it can look
for and load a font, which could be slow, especially if font-at
returns nil, meaning there's no font for the character.

So bottom line, something like this:

  (defun display-color-emoji-p (&optional frame)
    "DOC"
    (and (display-multi-font-p frame)
	 (let ((font-obj (font-at 0 (frame-selected-window frame) "😄")))
	   (and (fontp font-at)
		(member (font-get font-obj :family)
			list-of-known-emoji-font-families)))))

bug#56691: outline-minor-mode displays navigation arrow buttons as emojis

[Robert Pluim]

>>>>> On Fri, 29 Jul 2022 15:24:19 +0300, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Lars Ingebrigtsen <larsi@gnus.org>
    >> Cc: hello@paulwrankin.com,  56691@debbugs.gnu.org
    >> Date: Fri, 29 Jul 2022 13:32:57 +0200
    >> 
    >> Eli Zaretskii <eliz@gnu.org> writes:
    >> 
    >> > The test for Emoji display is not accurate enough.  Maybe we should
    >> > have a display-color-emoji-p predicate?  I added a FIXME there.
    >> 
    >> Sounds like a good idea.  What would that predicate look like?

    Eli> I think we can currently only do that by looking at the details of the
    Eli> build.  Currently, color Emoji are supported only by builds with Cairo
    Eli> and HarfBuzz on Unix and by macOS builds.

    Eli> But even that could be not enough, since the necessary font may not be
    Eli> installed.  So here's another idea: use font-at to check that it
    Eli> returns one of the known color Emoji fonts for an Emoji character.
    Eli> For example:

    Eli>   (font-get (font-at 0 nil "😄") :family)
    Eli>    => Symbola

There are dozens if not hundreds of fonts capable of displaying colour
emoji. You really want to list them all? Is it such a bad thing if we
donʼt use the emoji when we could?

    Eli> We can then compare the value with a list of known families of fonts
    Eli> that support color Emoji.  The downside of this is that it can look
    Eli> for and load a font, which could be slow, especially if font-at
    Eli> returns nil, meaning there's no font for the character.

    Eli> So bottom line, something like this:

    Eli>   (defun display-color-emoji-p (&optional frame)
    Eli>     "DOC"
    Eli>     (and (display-multi-font-p frame)
    Eli> 	 (let ((font-obj (font-at 0 (frame-selected-window frame) "😄")))
    Eli> 	   (and (fontp font-at)
    Eli> 		(member (font-get font-obj :family)
    Eli> 			list-of-known-emoji-font-families)))))

That will return nil here, but in this particular terminal emulator,
colour emoji display fine. Iʼve not been following, but I assume
thereʼs a "damn the torpedoes, I know what Iʼm doing" option for this
stuff.

Robert
-- 

bug#56691: outline-minor-mode displays navigation arrow buttons as emojis

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: Lars Ingebrigtsen <larsi@gnus.org>,  hello@paulwrankin.com,
>   56691@debbugs.gnu.org
> Date: Fri, 29 Jul 2022 14:48:01 +0200
> 
>     Eli>   (font-get (font-at 0 nil "😄") :family)
>     Eli>    => Symbola
> 
> There are dozens if not hundreds of fonts capable of displaying colour
> emoji.

Really, hundreds?  Are you sure?  Dozens don't scare me, and I thought
there are actually very few?

> Is it such a bad thing if we donʼt use the emoji when we could?

You mean, by default assume color Emoji aren't supported?  That'd
contradict what the documentation currently says, and is a strange
thing to do in such features.

>     Eli>   (defun display-color-emoji-p (&optional frame)
>     Eli>     "DOC"
>     Eli>     (and (display-multi-font-p frame)
>     Eli> 	 (let ((font-obj (font-at 0 (frame-selected-window frame) "😄")))
>     Eli> 	   (and (fontp font-at)
>     Eli> 		(member (font-get font-obj :family)
>     Eli> 			list-of-known-emoji-font-families)))))
> 
> That will return nil here, but in this particular terminal emulator,
> colour emoji display fine.

Terminal emulators is a separate issue.  If we need to support that,
we will have to let the user specify that.  (The current code doesn't
support that, either, right?)

> Iʼve not been following, but I assume thereʼs a "damn the torpedoes,
> I know what Iʼm doing" option for this stuff.

But the option's value is not a simple scalar, it is a list of
preferences, and they are supposed to be used in the order listed when
possible.  How do you reconcile that with "I know what I'm doing"?
Are users supposed to know in advance, for every display they use,
what are its capabilities?  And even if they do, are they supposed to
configure Emacs to use the lowest common denominator of those
displays?

bug#56691: outline-minor-mode displays navigation arrow buttons as emojis

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> But the option's value is not a simple scalar, it is a list of
> preferences, and they are supposed to be used in the order listed when
> possible.  How do you reconcile that with "I know what I'm doing"?

If there is only one element in `icon-preference', we could make
icon-string use that no matter whether we thing Emacs supports it or
not -- that'd let the user override the machinery completely, which
might be handy.

Or have elements like (emoji . force) to force it.

bug#56691: outline-minor-mode displays navigation arrow buttons as emojis

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Robert Pluim <rpluim@gmail.com>,  hello@paulwrankin.com,
>   56691@debbugs.gnu.org
> Date: Fri, 29 Jul 2022 15:38:39 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > But the option's value is not a simple scalar, it is a list of
> > preferences, and they are supposed to be used in the order listed when
> > possible.  How do you reconcile that with "I know what I'm doing"?
> 
> If there is only one element in `icon-preference', we could make
> icon-string use that no matter whether we thing Emacs supports it or
> not -- that'd let the user override the machinery completely, which
> might be handy.
> 
> Or have elements like (emoji . force) to force it.

OK, but then the feature becomes much less attractive, IMNSHO.
Basically, we are saying that all the smarts of selecting the best
available method will almost never see action.

And beyond that, there's a problem of how will users know which single
element to put there, unless they only ever work on a single display
type.  Even TTY frames vs GUI frames on the same machine could need
different methods.

So maybe a good compromise is to look at the build details after all,
and consider a system that can display color Emoji as being capable
without checking whether it actually is possible.  That still leaves
the TTY case unsolved, but maybe we can look at the name of the
terminal emulator?  Or have a separate defcustom for what happens on
TTY frames?

bug#56691: outline-minor-mode displays navigation arrow buttons as emojis

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> OK, but then the feature becomes much less attractive, IMNSHO.
> Basically, we are saying that all the smarts of selecting the best
> available method will almost never see action.

Yes, I agree.

> And beyond that, there's a problem of how will users know which single
> element to put there, unless they only ever work on a single display
> type.  Even TTY frames vs GUI frames on the same machine could need
> different methods.
>
> So maybe a good compromise is to look at the build details after all,
> and consider a system that can display color Emoji as being capable
> without checking whether it actually is possible.  That still leaves
> the TTY case unsolved, but maybe we can look at the name of the
> terminal emulator?  Or have a separate defcustom for what happens on
> TTY frames?

Perhaps we can allow the user to extend the predicates for each type
more easily -- for instance, by having (say) icon-emoji-predicate (etc)
that can be set to (x tty) (or whatever) in addition to the current
predicate functions?  Or something along those lines.

(I'll be mostly off-line for the rest of the day, but should be back
tomorrow and I'll take a look at this then.)

bug#56691: outline-minor-mode displays navigation arrow buttons as emojis

[Robert Pluim]

>>>>> On Fri, 29 Jul 2022 15:38:39 +0200, Lars Ingebrigtsen <larsi@gnus.org> said:

    Lars> Eli Zaretskii <eliz@gnu.org> writes:
    >> But the option's value is not a simple scalar, it is a list of
    >> preferences, and they are supposed to be used in the order listed when
    >> possible.  How do you reconcile that with "I know what I'm doing"?

    Lars> If there is only one element in `icon-preference', we could make
    Lars> icon-string use that no matter whether we thing Emacs supports it or
    Lars> not -- that'd let the user override the machinery completely, which
    Lars> might be handy.

    Lars> Or have elements like (emoji . force) to force it.

Or have it be like face specifications in defface, which can check
terminal properties.

Robert
-- 

bug#56691: outline-minor-mode displays navigation arrow buttons as emojis

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  hello@paulwrankin.com,
>   56691@debbugs.gnu.org
> Date: Fri, 29 Jul 2022 15:48:59 +0200
> 
> Or have it be like face specifications in defface, which can check
> terminal properties.

That's what Lars implemented.  We are discussing how to check one such
properties -- the ability to show color Emoji.

bug#56691: outline-minor-mode displays navigation arrow buttons as emojis

[Robert Pluim]

>>>>> On Fri, 29 Jul 2022 16:35:17 +0300, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Robert Pluim <rpluim@gmail.com>
    >> Cc: Lars Ingebrigtsen <larsi@gnus.org>,  hello@paulwrankin.com,
    >> 56691@debbugs.gnu.org
    >> Date: Fri, 29 Jul 2022 14:48:01 +0200
    >> 
    Eli> (font-get (font-at 0 nil "😄") :family)
    Eli> => Symbola
    >> 
    >> There are dozens if not hundreds of fonts capable of displaying colour
    >> emoji.

    Eli> Really, hundreds?  Are you sure?  Dozens don't scare me, and I thought
    Eli> there are actually very few?

Iʼm constantly surprised by the number of colour emoji fonts. It may
not be hundreds, but itʼs a lot.

    >> Is it such a bad thing if we donʼt use the emoji when we could?

    Eli> You mean, by default assume color Emoji aren't supported?  That'd
    Eli> contradict what the documentation currently says, and is a strange
    Eli> thing to do in such features.

Weʼd need a reliable way of implementing this:

    Eli> (defun display-color-emoji-p (&optional frame)

and I donʼt really like the idea of using a fixed list (but Iʼm not
implementing it 😀

    Eli> Terminal emulators is a separate issue.  If we need to support that,
    Eli> we will have to let the user specify that.  (The current code doesn't
    Eli> support that, either, right?)

    >> Iʼve not been following, but I assume thereʼs a "damn the torpedoes,
    >> I know what Iʼm doing" option for this stuff.

    Eli> But the option's value is not a simple scalar, it is a list of
    Eli> preferences, and they are supposed to be used in the order listed when
    Eli> possible.  How do you reconcile that with "I know what I'm doing"?
    Eli> Are users supposed to know in advance, for every display they use,
    Eli> what are its capabilities?  And even if they do, are they supposed to
    Eli> configure Emacs to use the lowest common denominator of those
    Eli> displays?

Youʼre conflating the defaults with the configurability. By default we
should try to do the right thing, but allow users to override that
(but you know that).

Robert
-- 

bug#56691: outline-minor-mode displays navigation arrow buttons as emojis

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> I think we can currently only do that by looking at the details of the
> build.  Currently, color Emoji are supported only by builds with Cairo
> and HarfBuzz on Unix and by macOS builds.

We don't support colour emojis on Windows?  I didn't know that.

> But even that could be not enough, since the necessary font may not be
> installed.  So here's another idea: use font-at to check that it
> returns one of the known color Emoji fonts for an Emoji character.
> For example:
>
>   (font-get (font-at 0 nil "😄") :family)
>    => Symbola

Ah, right.  I didn't know that Symbola had coverage for these
characters.  Perhaps a really simple fix would be to just choose a
character that we're pretty sure will never be supported by non-Emoji
fonts?  Let's see...

Symbola doesn't have support for LARGE ORANGE CIRCLE "🟠", so we could
try that instead.  I know, it's brittle, but so is listing all known
colour emoji fonts.

The real fix would be to look at the actual glyph data produced, and see
whether it's colourful or not, wouldn't it?  Is that possible?  Or
alternatively -- query the font whether it has colour glyphs, but I
don't know whether that's easy, either.  Anybody know?

bug#56691: outline-minor-mode displays navigation arrow buttons as emojis

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: hello@paulwrankin.com,  56691@debbugs.gnu.org
> Date: Sat, 30 Jul 2022 13:33:44 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I think we can currently only do that by looking at the details of the
> > build.  Currently, color Emoji are supported only by builds with Cairo
> > and HarfBuzz on Unix and by macOS builds.
> 
> We don't support colour emojis on Windows?  I didn't know that.

We don't.  The APIs used on Windows to display characters don't
support that, and more sophisticated APIs which do can only be called
from C++.

> Symbola doesn't have support for LARGE ORANGE CIRCLE "🟠", so we could
> try that instead.  I know, it's brittle, but so is listing all known
> colour emoji fonts.

Maybe.  It doesn't take care of issues raised by Robert, though.

> The real fix would be to look at the actual glyph data produced, and see
> whether it's colourful or not, wouldn't it?  Is that possible?

I don't know how to do that.  I don't think these aspects of the
glyphs are exposed to Emacs, but maybe I'm wrong.

> Or alternatively -- query the font whether it has colour glyphs, but
> I don't know whether that's easy, either.  Anybody know?

Not me.

bug#56691: outline-minor-mode displays navigation arrow buttons as emojis

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> The real fix would be to look at the actual glyph data produced, and see
> whether it's colourful or not, wouldn't it?  Is that possible?

Only if the font is already opened, and it's a fairly slow operation
that involves a roundtrip to the X server outside of Cairo.  One of the
Java X servers also supports color fonts, but they seem to be
implemented as an overlay, because if I draw some color glyphs to a
window and then use XGetImage, those glyphs do not show up in the
resulting image, even though they do show up on display.

> Or alternatively -- query the font whether it has colour glyphs, but I
> don't know whether that's easy, either.  Anybody know?

I think FC_COLOR gets you halfway there, but it says nothing about Emoji
specifically.

There is no equivalent on Haiku or NS AFAICT, and on MS Windows we
simply don't support color fonts.

bug#56691: outline-minor-mode displays navigation arrow buttons as emojis

[Lars Ingebrigtsen]

Po Lu <luangruo@yahoo.com> writes:

> Only if the font is already opened, and it's a fairly slow operation
> that involves a roundtrip to the X server outside of Cairo.  One of the
> Java X servers also supports color fonts, but they seem to be
> implemented as an overlay, because if I draw some color glyphs to a
> window and then use XGetImage, those glyphs do not show up in the
> resulting image, even though they do show up on display.

Hm, interesting...

>> Or alternatively -- query the font whether it has colour glyphs, but I
>> don't know whether that's easy, either.  Anybody know?
>
> I think FC_COLOR gets you halfway there, but it says nothing about Emoji
> specifically.

Thanks.  If it doesn't have FC_COLOR, then it definitely isn't an Emoji
font, so I suspect we'll be able to weed out most of the false
positives.  So it might be useful as a test in there somewhere.

> There is no equivalent on Haiku or NS AFAICT, and on MS Windows we
> simply don't support color fonts.

FC_COLOR isn't defined on NS?

bug#56691: outline-minor-mode displays navigation arrow buttons as emojis

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> FC_COLOR isn't defined on NS?

No, it's specific to Fontconfig, which is not used on NS.

bug#56691: outline-minor-mode displays navigation arrow buttons as emojis

[Robert Pluim]

>>>>> On Sun, 31 Jul 2022 08:51:41 +0800, Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org> said:

    Po> Lars Ingebrigtsen <larsi@gnus.org> writes:
    >> FC_COLOR isn't defined on NS?

    Po> No, it's specific to Fontconfig, which is not used on NS.

On NS you have

          if ((sym_traits & kCTFontTraitColorGlyphs)

(macfont.m:2437)

Robert
-- 

bug#56691: outline-minor-mode displays navigation arrow buttons as emojis

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Robert Pluim <rpluim@gmail.com> writes:

>>>>>> On Sun, 31 Jul 2022 08:51:41 +0800, Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org> said:
>
>     Po> Lars Ingebrigtsen <larsi@gnus.org> writes:
>     >> FC_COLOR isn't defined on NS?
>
>     Po> No, it's specific to Fontconfig, which is not used on NS.
>
> On NS you have
>
>           if ((sym_traits & kCTFontTraitColorGlyphs)
>
> (macfont.m:2437)
>
> Robert

Nice.

I will see if that exists in GNUstep in some form.

bug#56691: outline-minor-mode displays navigation arrow buttons as emojis

[Lars Ingebrigtsen]

Po Lu <luangruo@yahoo.com> writes:

>> On NS you have
>>
>>           if ((sym_traits & kCTFontTraitColorGlyphs)
>>
>> (macfont.m:2437)
>>
>> Robert
>
> Nice.
>
> I will see if that exists in GNUstep in some form.

Great!  I guess we should add a C-level predicate like font-color-p?

bug#56691: outline-minor-mode displays navigation arrow buttons as emojis

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Great!  I guess we should add a C-level predicate like font-color-p?

What would it accept? Font entities or objects?

I think the better solution would be to add a separate "color" field to
font specs, entities, and objects.

bug#56691: outline-minor-mode displays navigation arrow buttons as emojis

[Lars Ingebrigtsen]

Po Lu <luangruo@yahoo.com> writes:

> What would it accept? Font entities or objects?

Like many of the other font-* functions -- both.

> I think the better solution would be to add a separate "color" field to
> font specs, entities, and objects.

That would also be fine if that doesn't lead to incompatibilities.

bug#56691: outline-minor-mode displays navigation arrow buttons as emojis

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Robert Pluim <rpluim@gmail.com>,  Eli Zaretskii <eliz@gnu.org>,
>   56691@debbugs.gnu.org,  hello@paulwrankin.com
> Date: Mon, 01 Aug 2022 18:42:55 +0800
> 
> Lars Ingebrigtsen <larsi@gnus.org> writes:
> 
> > Great!  I guess we should add a C-level predicate like font-color-p?
> 
> What would it accept? Font entities or objects?

What every other display-*-p function accepts: a frame or a terminal.

> I think the better solution would be to add a separate "color" field to
> font specs, entities, and objects.

That's orthogonal, and can only be done once the predicate is
implemented.

bug#56691: outline-minor-mode displays navigation arrow buttons as emojis

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> > Great!  I guess we should add a C-level predicate like font-color-p?
>> 
>> What would it accept? Font entities or objects?
>
> What every other display-*-p function accepts: a frame or a terminal.

This is about the primitive that display-color-fonts-p will use, so it
should take a font object (if we add it).

bug#56691: outline-minor-mode displays navigation arrow buttons as emojis

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Po Lu <luangruo@yahoo.com>,  rpluim@gmail.com,  56691@debbugs.gnu.org,
>   hello@paulwrankin.com
> Date: Mon, 01 Aug 2022 13:51:04 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> > Great!  I guess we should add a C-level predicate like font-color-p?
> >> 
> >> What would it accept? Font entities or objects?
> >
> > What every other display-*-p function accepts: a frame or a terminal.
> 
> This is about the primitive that display-color-fonts-p will use, so it
> should take a font object (if we add it).

Why should it care about a specific font?  And how will you obtain a
font in these cases to begin with?  Fonts are extremely platform- and
user-configuration-dependent, so I see no reason to try to deal with
them.

bug#56691: outline-minor-mode displays navigation arrow buttons as emojis

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Why should it care about a specific font?  And how will you obtain a
> font in these cases to begin with?  Fonts are extremely platform- and
> user-configuration-dependent, so I see no reason to try to deal with
> them.

I don't follow you at all here.

We've got an emoji to display, so we look up what font Emacs wants to
display it with, and then we check whether that font is an emoji font or
not (by checking that it's a colour font).

(Let's ignore the fact that black-and-white emoji fonts exists, too. 🫠)

bug#56691: outline-minor-mode displays navigation arrow buttons as emojis

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: luangruo@yahoo.com,  rpluim@gmail.com,  56691@debbugs.gnu.org,
>   hello@paulwrankin.com
> Date: Mon, 01 Aug 2022 14:36:41 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Why should it care about a specific font?  And how will you obtain a
> > font in these cases to begin with?  Fonts are extremely platform- and
> > user-configuration-dependent, so I see no reason to try to deal with
> > them.
> 
> I don't follow you at all here.
> 
> We've got an emoji to display, so we look up what font Emacs wants to
> display it with, and then we check whether that font is an emoji font or
> not (by checking that it's a colour font).

I thought we agreed this was not a good idea?  First, it can be slow,
if there are no such fonts.  Next, the fonts might be set up so that a
B&W font is selected while a color font does exist.  Etc. etc. -- it
looks like we gain very little or nothing at all for all this trouble.

Faced with these complications, I thought we decided just to test for
the _potential_ of displaying color Emoji, and leave it to the user to
set their systems so that the potential is realized, or customize
Emacs to disable color Emoji.  That sounds much easier, more reliable,
and on top of that can be extended to TTY frames that are capable of
displaying color Emoji, whereas what you propose isn't.

bug#56691: outline-minor-mode displays navigation arrow buttons as emojis

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Faced with these complications, I thought we decided just to test for
> the _potential_ of displaying color Emoji, and leave it to the user to
> set their systems so that the potential is realized, or customize
> Emacs to disable color Emoji.  That sounds much easier, more reliable,
> and on top of that can be extended to TTY frames that are capable of
> displaying color Emoji, whereas what you propose isn't.

I'm proposing that we should have a primitive that makes it possible to
have the defaults work for most people.  There should be overrides to
allow the user to fine-grained control of this, of course, but that's a
separate issue.

bug#56691: outline-minor-mode displays navigation arrow buttons as emojis

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: luangruo@yahoo.com,  rpluim@gmail.com,  56691@debbugs.gnu.org,
>   hello@paulwrankin.com
> Date: Tue, 02 Aug 2022 11:54:26 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Faced with these complications, I thought we decided just to test for
> > the _potential_ of displaying color Emoji, and leave it to the user to
> > set their systems so that the potential is realized, or customize
> > Emacs to disable color Emoji.  That sounds much easier, more reliable,
> > and on top of that can be extended to TTY frames that are capable of
> > displaying color Emoji, whereas what you propose isn't.
> 
> I'm proposing that we should have a primitive that makes it possible to
> have the defaults work for most people.

How would what I proposed miss that goal?

bug#56691: outline-minor-mode displays navigation arrow buttons as emojis

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> I'm proposing that we should have a primitive that makes it possible to
>> have the defaults work for most people.
>
> How would what I proposed miss that goal?

It would use the Symbola font on Linux when there's no emoji font
installed (for the emojis) by default.  What I'm proposing would fix
that.

bug#56691: outline-minor-mode displays navigation arrow buttons as emojis

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: luangruo@yahoo.com,  rpluim@gmail.com,  56691@debbugs.gnu.org,
>   hello@paulwrankin.com
> Date: Tue, 02 Aug 2022 13:20:47 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> I'm proposing that we should have a primitive that makes it possible to
> >> have the defaults work for most people.
> >
> > How would what I proposed miss that goal?
> 
> It would use the Symbola font on Linux when there's no emoji font
> installed (for the emojis) by default.

Yes, but is it reasonable to expect such a system?  I mean, if someone
builds an Emacs capable of displaying color Emoji, isn't it reasonable
to expect him/her to install a suitable font as well?  Color Emoji are
a "hot" feature, so I'd expect that.

Also, do distros come without a color Emoji font nowadays?  Because
Symbola AFAIK needs to be installed, it isn't by default, so if a
color Emoji font _is_ available OOTB, I think the chances for the
problems you mention are very small, and/or are easily fixed.

bug#56691: outline-minor-mode displays navigation arrow buttons as emojis

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

> Yes, but is it reasonable to expect such a system?  I mean, if someone
> builds an Emacs capable of displaying color Emoji, isn't it reasonable
> to expect him/her to install a suitable font as well?  Color Emoji are
> a "hot" feature, so I'd expect that.

The problem is that Emacs is built with color Emoji support by default.
Most people do not know the necessary compile-time options to turn that
support off.

> Also, do distros come without a color Emoji font nowadays?  Because
> Symbola AFAIK needs to be installed, it isn't by default, so if a
> color Emoji font _is_ available OOTB, I think the chances for the
> problems you mention are very small, and/or are easily fixed.

Symbola comes with most systems OOTB.  I remember Firefox displaying
Emoji using that font not too long ago, on a fresh install of RHEL 7.9.

bug#56691: outline-minor-mode displays navigation arrow buttons as emojis

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Lars Ingebrigtsen <larsi@gnus.org>,  rpluim@gmail.com,
>   56691@debbugs.gnu.org,  hello@paulwrankin.com
> Date: Tue, 02 Aug 2022 19:57:55 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Yes, but is it reasonable to expect such a system?  I mean, if someone
> > builds an Emacs capable of displaying color Emoji, isn't it reasonable
> > to expect him/her to install a suitable font as well?  Color Emoji are
> > a "hot" feature, so I'd expect that.
> 
> The problem is that Emacs is built with color Emoji support by default.
> Most people do not know the necessary compile-time options to turn that
> support off.
> 
> > Also, do distros come without a color Emoji font nowadays?  Because
> > Symbola AFAIK needs to be installed, it isn't by default, so if a
> > color Emoji font _is_ available OOTB, I think the chances for the
> > problems you mention are very small, and/or are easily fixed.
> 
> Symbola comes with most systems OOTB.  I remember Firefox displaying
> Emoji using that font not too long ago, on a fresh install of RHEL 7.9.

<Shrug> I still feel it's wrong for a capability predicate to load
fonts etc., and generally be potentially very slow and expensive.

bug#56691: outline-minor-mode displays navigation arrow buttons as emojis

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Po Lu <luangruo@yahoo.com>
>> Cc: Lars Ingebrigtsen <larsi@gnus.org>,  rpluim@gmail.com,
>>   56691@debbugs.gnu.org,  hello@paulwrankin.com
>> Date: Tue, 02 Aug 2022 19:57:55 +0800
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > Yes, but is it reasonable to expect such a system?  I mean, if someone
>> > builds an Emacs capable of displaying color Emoji, isn't it reasonable
>> > to expect him/her to install a suitable font as well?  Color Emoji are
>> > a "hot" feature, so I'd expect that.
>> 
>> The problem is that Emacs is built with color Emoji support by default.
>> Most people do not know the necessary compile-time options to turn that
>> support off.
>> 
>> > Also, do distros come without a color Emoji font nowadays?  Because
>> > Symbola AFAIK needs to be installed, it isn't by default, so if a
>> > color Emoji font _is_ available OOTB, I think the chances for the
>> > problems you mention are very small, and/or are easily fixed.
>> 
>> Symbola comes with most systems OOTB.  I remember Firefox displaying
>> Emoji using that font not too long ago, on a fresh install of RHEL 7.9.
>
> <Shrug> I still feel it's wrong for a capability predicate to load
> fonts etc., and generally be potentially very slow and expensive.

Maybe we could only look for fonts once (on each terminal), and then
cache the result?

bug#56691: outline-minor-mode displays navigation arrow buttons as emojis

[Lars Ingebrigtsen]

Po Lu <luangruo@yahoo.com> writes:

> Maybe we could only look for fonts once (on each terminal), and then
> cache the result?

Yes, I was thinking of some kind of cache here, but haven't had time to
rework things here yet.

bug#56691: outline-minor-mode displays navigation arrow buttons as emojis

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Yes, I was thinking of some kind of cache here, but haven't had time to
> rework things here yet.

There is already a font cache, which I think does cache negative
results.

bug#56691: outline-minor-mode displays navigation arrow buttons as emojis

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

> That's orthogonal, and can only be done once the predicate is
> implemented.

How so?  FC_COLOR is used during the font matching process, so it can
only be a font spec or entity attribute.

So a display-specific predicate could only be implemented like this:

  (defun display-color-font-p (frame)
    "DOC"
    (find-font (font-spec :color t) frame))

bug#56691: outline-minor-mode displays navigation arrow buttons as emojis

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: larsi@gnus.org,  rpluim@gmail.com,  56691@debbugs.gnu.org,
>   hello@paulwrankin.com
> Date: Mon, 01 Aug 2022 20:16:20 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > That's orthogonal, and can only be done once the predicate is
> > implemented.
> 
> How so?  FC_COLOR is used during the font matching process, so it can
> only be a font spec or entity attribute.
> 
> So a display-specific predicate could only be implemented like this:
> 
>   (defun display-color-font-p (frame)
>     "DOC"
>     (find-font (font-spec :color t) frame))

I thought we wanted a capability indication, not something that
actually looks for installed fonts.  AFAIU, if there are no color
fonts on the user's system, the above will tell Emacs color fonts
aren't supported.  That's not what we wanted, based on earlier
discussions.

bug#56691: outline-minor-mode displays navigation arrow buttons as emojis

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

> I thought we wanted a capability indication, not something that
> actually looks for installed fonts.  AFAIU, if there are no color
> fonts on the user's system, the above will tell Emacs color fonts
> aren't supported.  That's not what we wanted, based on earlier
> discussions.

Then this could be implemented very simply:

  (or (featurep 'haiku)
      (featurep 'cocoa)
      (featurep 'cairo))

bug#56691: outline-minor-mode displays navigation arrow buttons as emojis

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: larsi@gnus.org,  rpluim@gmail.com,  56691@debbugs.gnu.org,
>   hello@paulwrankin.com
> Date: Mon, 01 Aug 2022 21:20:28 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I thought we wanted a capability indication, not something that
> > actually looks for installed fonts.  AFAIU, if there are no color
> > fonts on the user's system, the above will tell Emacs color fonts
> > aren't supported.  That's not what we wanted, based on earlier
> > discussions.
> 
> Then this could be implemented very simply:
> 
>   (or (featurep 'haiku)
>       (featurep 'cocoa)
>       (featurep 'cairo))

That's what I thought we agreed to do, yes.  (But do we only support
Cairo with HarfBuzz?)

bug#56691: outline-minor-mode displays navigation arrow buttons as emojis

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

> That's what I thought we agreed to do, yes.  (But do we only support
> Cairo with HarfBuzz?)

No, color fonts are supported under Cairo even if Emacs isn't built with
HarfBuzz.

bug#56691: outline-minor-mode displays navigation arrow buttons as emojis

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: larsi@gnus.org,  rpluim@gmail.com,  56691@debbugs.gnu.org,
>   hello@paulwrankin.com
> Date: Mon, 01 Aug 2022 21:47:37 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > That's what I thought we agreed to do, yes.  (But do we only support
> > Cairo with HarfBuzz?)
> 
> No, color fonts are supported under Cairo even if Emacs isn't built with
> HarfBuzz.

But we are talking about color Emoji, not just about color fonts.
Will a Cairo build without HarfBuzz support Emoji sequences?

bug#56691: outline-minor-mode displays navigation arrow buttons as emojis

[Robert Pluim]

>>>>> On Mon, 01 Aug 2022 16:53:59 +0300, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Po Lu <luangruo@yahoo.com>
    >> Cc: larsi@gnus.org,  rpluim@gmail.com,  56691@debbugs.gnu.org,
    >> hello@paulwrankin.com
    >> Date: Mon, 01 Aug 2022 21:47:37 +0800
    >> 
    >> Eli Zaretskii <eliz@gnu.org> writes:
    >> 
    >> > That's what I thought we agreed to do, yes.  (But do we only support
    >> > Cairo with HarfBuzz?)
    >> 
    >> No, color fonts are supported under Cairo even if Emacs isn't built with
    >> HarfBuzz.

    Eli> But we are talking about color Emoji, not just about color fonts.
    Eli> Will a Cairo build without HarfBuzz support Emoji sequences?

Yes, but they wonʼt display anywhere near as well as with Harfbuzz:
they tend to show up as double/triple/more width.

Robert
-- 

bug#56691: outline-minor-mode displays navigation arrow buttons as emojis

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

So, has there been a conclusion here on what to do or not?
It is really not acceptable for Emacs to display arrow buttons in a form
that depends on the fonts installed on a user's system.  Why can't we
default to what Custom does, which is to use an SVG (or failing that,
PBM) image instead?

I've looked and cannot find a single other program that uses color Emoji
to replace arrow textures, when the latter are possible.

bug#56691: outline-minor-mode displays navigation arrow buttons as emojis

[Lars Ingebrigtsen]

Po Lu <luangruo@yahoo.com> writes:

> So, has there been a conclusion here on what to do or not?
> It is really not acceptable for Emacs to display arrow buttons in a form
> that depends on the fonts installed on a user's system.  Why can't we
> default to what Custom does, which is to use an SVG (or failing that,
> PBM) image instead?

We want to have a way to say whether we can display emojis, so it's a
good test case anyway.  Whether we want to use something else for these
things in the long run is a separate issue.

bug#56691: outline-minor-mode displays navigation arrow buttons as emojis

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> We want to have a way to say whether we can display emojis, so it's a
> good test case anyway.

Isn't the role of Emoji test case already taken by etc/HELLO?

> Whether we want to use something else for these things in the long run
> is a separate issue.

Wasn't "using emojis for these things" the original issue here, as
indicated by the subject line?

bug#56691: outline-minor-mode displays navigation arrow buttons as emojis

[Lars Ingebrigtsen]

Po Lu <luangruo@yahoo.com> writes:

>> We want to have a way to say whether we can display emojis, so it's a
>> good test case anyway.
>
> Isn't the role of Emoji test case already taken by etc/HELLO?

How on earth is etc/HELLO being used as a test for whether we can detect
emoji support?

>> Whether we want to use something else for these things in the long run
>> is a separate issue.
>
> Wasn't "using emojis for these things" the original issue here, as
> indicated by the subject line?

I don't think it's an interesting issue.

bug#56691: outline-minor-mode displays navigation arrow buttons as emojis

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> How on earth is etc/HELLO being used as a test for whether we can detect
> emoji support?

Because Emoji will not be displayed if we cannot?

> I don't think it's an interesting issue.

It may not be an interesting issue, but it's the issue that is actually
relevant for Emacs users.

bug#56691: outline-minor-mode displays navigation arrow buttons as emojis

[Jim Porter]

On 8/10/2022 4:39 AM, Po Lu via Bug reports for GNU Emacs, the Swiss 
army knife of text editors wrote:
> So, has there been a conclusion here on what to do or not?
> It is really not acceptable for Emacs to display arrow buttons in a form
> that depends on the fonts installed on a user's system.  Why can't we
> default to what Custom does, which is to use an SVG (or failing that,
> PBM) image instead?

It looks like icons.el supports defining an image to use via 
'define-icon', so shouldn't this "just" be a matter of defining that 
appropriately? Then users can customize 'icon-preference' to their 
hearts' content. I tried looking into how to do that, but it wasn't 
clear to me how to use an image with 'define-icon'.

I agree that we should provide image files for these icons though, 
especially since we already use these images in Customize.

bug#56691: outline-minor-mode displays navigation arrow buttons as emojis

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Jim Porter <jporterbugs@gmail.com> writes:

> It looks like icons.el supports defining an image to use via
> 'define-icon', so shouldn't this "just" be a matter of defining that
> appropriately? Then users can customize 'icon-preference' to their
> hearts' content. I tried looking into how to do that, but it wasn't
> clear to me how to use an image with 'define-icon'.

Yeah, I opened an issue about the confusing customization interface
yesterday.

bug#56691: outline-minor-mode displays navigation arrow buttons as emojis

[Lars Ingebrigtsen]

Jim Porter <jporterbugs@gmail.com> writes:

> I agree that we should provide image files for these icons though,
> especially since we already use these images in Customize.

Yeah, and they look awful.

But, yes, I expect theme writers to add images (SVGs and PNGs as
fallbacks) to the icons, but about one third of our audience doesn't use
GUI Emacs.

bug#56691: outline-minor-mode displays navigation arrow buttons as emojis

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Yeah, and they look awful.

Really? They are AFAIK the same icons used by the default GTK
stylesheet.  Emoji definitely look worse, and what the Emoji displays as
is also highly system-dependent.

> But, yes, I expect theme writers to add images (SVGs and PNGs

What's wrong with XPM, which is the canonical non-scalable image format
used in Emacs? Icon authors should strive to provide SVGs, XPMs and
PBMs, to ensure that the icon can always be displayed on all Emacs
builds.

> as fallbacks) to the icons, but about one third of our audience
> doesn't use GUI Emacs.

One-third seems like a gross overstatement.

bug#56691: outline-minor-mode displays navigation arrow buttons as emojis

[Lars Ingebrigtsen]

Po Lu <luangruo@yahoo.com> writes:

> What's wrong with XPM, which is the canonical non-scalable image format
> used in Emacs? Icon authors should strive to provide SVGs, XPMs and
> PBMs, to ensure that the icon can always be displayed on all Emacs
> builds.

XPMs and PBMs are irrelevant -- virtually all GUI Emacs builds can
display PNGs.

>> as fallbacks) to the icons, but about one third of our audience
>> doesn't use GUI Emacs.
>
> One-third seems like a gross overstatement.

It was what the Emacs survey said.

bug#56691: outline-minor-mode displays navigation arrow buttons as emojis

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> XPMs and PBMs are irrelevant -- virtually all GUI Emacs builds can
> display PNGs.

Virtually all, but not all.  Especially not when you are first bringing
up a port, when only PBM images are available.  Developers should always
include XPM and PBM images as a courtesy to users.  I see no reason to
use PNG images for icons instead of the traditional formats.

> It was what the Emacs survey said.

How many people responded? And even if the results are real, that
doesn't mean we should bend over our backs to support those users.

bug#56691: outline-minor-mode displays navigation arrow buttons as emojis

[Lars Ingebrigtsen]

Po Lu <luangruo@yahoo.com> writes:

> Virtually all, but not all.  Especially not when you are first bringing
> up a port, when only PBM images are available.  Developers should always
> include XPM and PBM images as a courtesy to users.  I see no reason to
> use PNG images for icons instead of the traditional formats.

Developers definitely should not include those, because it's just
makework with no real world effect.

>> It was what the Emacs survey said.
>
> How many people responded? And even if the results are real, that
> doesn't mean we should bend over our backs to support those users.

Neither should we ignore them.

bug#56691: outline-minor-mode displays navigation arrow buttons as emojis

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Developers definitely should not include those, because it's just
> makework with no real world effect.

What kind of makework is that? Why doesn't it have a real world effect?
PBms are guaranteed to be available in all Emacs builds, including
during the bring-up of a GUI port (where it is normally not possible to
display any other images for the first few weeks), and XPMs are
guaranteed to be available in almost every other situation.  XPMs also
work on colormapped displays, which cannot be said for other color image
formats we support.

> Neither should we ignore them.

And how are we are ignoring them by defaulting to images for icons? If
the :display property is not supported by the terminal, then the text
underneath will be automatically displayed instead.

bug#56691: outline-minor-mode displays navigation arrow buttons as emojis

[Jim Porter]

[-- Attachment #1: Type: text/plain, Size: 996 bytes --]

On 8/12/2022 7:57 AM, Lars Ingebrigtsen wrote:
> Jim Porter <jporterbugs@gmail.com> writes:
> 
>> I agree that we should provide image files for these icons though,
>> especially since we already use these images in Customize.
> 
> Yeah, and they look awful.
> 
> But, yes, I expect theme writers to add images (SVGs and PNGs as
> fallbacks) to the icons, but about one third of our audience doesn't use
> GUI Emacs.

You mean these right? (See attached.) I don't find them terribly 
offensive, though I also certainly wouldn't mind if they were updated. 
They're a bit "heavy".

If there's interest, I could try to adjust them so that they're a bit 
more pleasing to the eye (subject to individual tastes, of course). Then 
maybe we could use those for outline-mode too, which would have the 
added bonus of being a nice example of how to do "everything" with 
'define-icon': using emojis, symbols, text, and - assuming it's possible 
- multiple different image types to fall back to as needed.

[-- Attachment #2: arrows.png --]
[-- Type: image/png, Size: 5381 bytes --]

bug#56691: outline-minor-mode displays navigation arrow buttons as emojis

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Jim Porter <jporterbugs@gmail.com> writes:

> You mean these right? (See attached.) I don't find them terribly
> offensive, though I also certainly wouldn't mind if they were
> updated. They're a bit "heavy".

They look better than the default Outline icons under the Symbola font,
simply because the images representing both states are the same size.

bug#56691: outline-minor-mode displays navigation arrow buttons as emojis

[Lars Ingebrigtsen]

[-- Attachment #1: Type: text/plain, Size: 233 bytes --]

Po Lu <luangruo@yahoo.com> writes:

> They look better than the default Outline icons under the Symbola font,
> simply because the images representing both states are the same size.

The Symbola Outline icons are of identical size:


[-- Attachment #2: Type: image/png, Size: 1348 bytes --]

bug#56691: outline-minor-mode displays navigation arrow buttons as emojis

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Po Lu <luangruo@yahoo.com> writes:
>
>> They look better than the default Outline icons under the Symbola font,
>> simply because the images representing both states are the same size.
>
> The Symbola Outline icons are of identical size:

You can clearly see that the symbol on top is wider than the one on the
bottom.

bug#56691: outline-minor-mode displays navigation arrow buttons as emojis

[Lars Ingebrigtsen]

Po Lu <luangruo@yahoo.com> writes:

>> The Symbola Outline icons are of identical size:
>
> You can clearly see that the symbol on top is wider than the one on the
> bottom.

They glyphs are of identical size.

bug#56691: outline-minor-mode displays navigation arrow buttons as emojis

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Po Lu <luangruo@yahoo.com> writes:
>
>>> The Symbola Outline icons are of identical size:
>>
>> You can clearly see that the symbol on top is wider than the one on the
>> bottom.
>
> They glyphs are of identical size.

They are not, as you can see from this:

  ELISP> (string-pixel-width "⯆")
  10 (#o12, #xa, ?\C-j)
  ELISP> (string-pixel-width "⯈")
  9 (#o11, #x9, ?\C-i)

and from how the vertical box lines on the bottom are not aligned.  Both
on your system and on mine.

bug#56691: outline-minor-mode displays navigation arrow buttons as emojis

[Lars Ingebrigtsen]

Po Lu <luangruo@yahoo.com> writes:

> They are not, as you can see from this:
>
>   ELISP> (string-pixel-width "⯆")
>   10 (#o12, #xa, ?\C-j)
>   ELISP> (string-pixel-width "⯈")
>   9 (#o11, #x9, ?\C-i)
>
> and from how the vertical box lines on the bottom are not aligned.  Both
> on your system and on mine.

You are correct.

bug#56691: outline-minor-mode displays navigation arrow buttons as emojis

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> You are correct.

(Or you were; icons updated.)

bug#56691: outline-minor-mode displays navigation arrow buttons as emojis

[Lars Ingebrigtsen]

Jim Porter <jporterbugs@gmail.com> writes:

> If there's interest, I could try to adjust them so that they're a bit
> more pleasing to the eye (subject to individual tastes, of
> course). Then maybe we could use those for outline-mode too, which
> would have the added bonus of being a nice example of how to do
> "everything" with 'define-icon': using emojis, symbols, text, and -
> assuming it's possible - multiple different image types to fall back
> to as needed.

Yes, the Widgets arrows will, of course, also be defined with
define-icon.  (And all other similar things in Emacs.)

bug#56691: outline-minor-mode displays navigation arrow buttons as emojis

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Yes, the Widgets arrows will, of course, also be defined with
> define-icon.  (And all other similar things in Emacs.)

Which will be a serious step backwards, if the icons continue to be
text by default.

bug#56691: outline-minor-mode displays navigation arrow buttons as emojis

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Robert Pluim <rpluim@gmail.com>,  Eli Zaretskii <eliz@gnu.org>,
>   56691@debbugs.gnu.org,  hello@paulwrankin.com
> Date: Mon, 01 Aug 2022 12:36:21 +0200
> 
> Great!  I guess we should add a C-level predicate like font-color-p?

Please call it display-color-fonts-p, to be consistent with the other
similar capacity predicates.

bug#56691: outline-minor-mode displays navigation arrow buttons as emojis

[Visuwesh]

[சனி ஜூலை 23, 2022] Lars Ingebrigtsen wrote:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>> Why is it a problem not to override that option, when its default
>> value will cause the buttons to be shown in Help buffers?
>
> I don't follow -- the default value of outline-minor-mode-use-buttons is
> nil, so there'd be no buttons in the *Help* buffer.
>
>> Put it another way: why should we consider Help buffers under Outline
>> Minor mode be any different from any other buffer under that mode?
>
> Mainly because other modes that use the option are edit-oriented modes,
> so there the buttons are pretty annoying.

Which reminds me: why don't we buttonise the outline level marker?  In
org-mode, for example, I buttonise the stars to expand or collapse the
heading.  I could see this working okay-ish for programming modes too.

bug#56691: outline-minor-mode displays navigation arrow buttons as emojis

[Eli Zaretskii]

> Date: Fri, 22 Jul 2022 14:57:11 +1000
> From:  "Paul W. Rankin" via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> Summary:
> 
> First discovered in the describe-bindings buffer (C-h b). Screenshot: 
> http://0x0.st/ojN5.png
> 
> Buffers using outline-minor-mode will attempt to add navigation arrow 
> buttons (i.e. show/hide) displaying emojis instead of arrows or text 
> representation.

To get what you want, customize the variable
outline-minor-mode-buttons to swap the two sub-lists in the default
value.

> 1. $emacs -Q
> 2. C-h b
> 
> Expected results:
> 
> Buffer navigation arrows are arrows.
> 
> Actual results:
> 
> Buffer navigation arrows are emojis.

I see nothing wrong in the default behavior, FWIW.

> Notes for the committer:
> 
> Do not use emojis in software designed for adults; what you see as 
> whimsical appears to others as childish and unprofessional. While I 
> cannot speak for vision-impaired users, this also raises the issue of 
> whether emojis appropriated for functional use create yet another 
> difficulty for those requiring screen readers.
> 
> As always, if you wish to add a feature to Emacs (i.e. not fix a bug) -- 
> do not make that new feature enabled by default! This is incredibly 
> rude. Document the feature and allow others to make their own choices.

These are your opinions, and you are entitled to them.  But they
aren't necessarily absolutely true.  The important part is that this
should be easily customizable.  I don't think we are there yet, so
some work is clearly in order.  But not necessarily to change the
default.

Thanks.

bug#56691: outline-minor-mode displays navigation arrow buttons as emojis

[Juri Linkov]

> First discovered in the describe-bindings buffer (C-h b). Screenshot:
> http://0x0.st/ojN5.png

Your emoji buttons color is quite bearable, my emoji buttons color is much worse:
it's glamourish orange.

bug#56691: reopen

[Paul W. Rankin via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Bug was closed without resolving underlying issue. Reopening.

bug#56691: Better override

[Paul W. Rankin via Bug reports for GNU Emacs, the Swiss army knife of text editors]

For others as frustrated by this, most reliable way I’ve found to 
override...

     (with-eval-after-load 'outline
       (advice-add 'outline--valid-emoji-p :override 'ignore))