Re: High-res Customize icons

[Eli Zaretskii <eliz@gnu.org>]

> From: chad <yandros@gmail.com>
> Date: Thu, 23 Apr 2020 16:23:27 -0700
> Cc: Werner LEMBERG <wl@gnu.org>, Juri Linkov <juri@linkov.net>, Yuan Fu <casouri@gmail.com>, 
> 	Yuri Khan <yuri.v.khan@gmail.com>, Clément Pit-Claudel <cpitclaudel@gmail.com>, 
> 	EMACS development team <emacs-devel@gnu.org>
> 
> I know that you don't like the idea of using fonts for icons and emoji inside emacs. I would ask you to
> reconsider, for two (and a half) reasons:

Thanks.  I already did reconsider that, based on what was posted in
this thread, and my latest opinion is in the message I sent a few
minutes back, in response to Stefan's (and more about it below).

> 1.) This support us ubiquitous in the "modern" toolchains used by new developers, especially in ubiquitous
> real-time chat systems, internet fora, and the like. Anecdotally, I know emacs' lack of support for emoji (with
> the additional refinement of support being added to and then removed from emacs under macOS) has
> caused multiple smart coders to abandon emacs very quickly.
> 
> 2.) The all-the-icons package was created to consolidate multiple packages that were installing these fonts
> for their own uses, especially packages that update the mode line and the various file browsers (which is
> why all-the-icons uses those screenshots specifically), and also MUA code. Put another way, people are
> very likely to use some of these fonts inside emacs anyway. The difference is in how much effort it takes --
> whether they see it mostly in packages like Spacemacs, Doom, and mu4e, or in "plain emacs".
> 
> 2.5) These fonts are very popular amongst developers who use "fancy prompt" packages for their shell, so
> that their prompt includes things like git status, python/docker/ruby/etc env markers, battery indicators, and
> similar. These features are pretty young (compared to most of us, anyway), but are nigh-ubiquitous among
> newer developers I've seen; the features are both built into many new shells and have spawned a
> surprisingly large variety of "cool prompt" packages for a wide variety of shells (including several for bash). I
> mention this as evidence that installing fonts is not at all a high bar for most developers.

Those reasons are valid for third-party package developers.  As I
wrote, I understand very well why they are doing that.  Moreover, no
matter what I say, I cannot cause anyone to do things differently in
their own packages.  I won't even try.  People who like the results
are free to use those packages, they are free software.

But for core Emacs features we cannot be guided by convenience alone,
nor by the least-resistance pathways.  We must do it The Right Way,
the way that the technology dictates, the way that will not cause
clashes with other Emacs features and with future developments.

Take the example of the various ligature-using packages, which use the
prettify-symbols-mode.  Their popularity notwithstanding, this is the
wrong way of adding support for ligatures to Emacs.  It is wrong to
tell users to install a certain font or a bunch of fonts, and then
manually configure each ligature by peeking inside the font and
figuring out the glyph code for each ligature.  The right way of doing
that is to use a text-shaping engine which will work with the font to
produce the ligatures automatically.  Which is what we did when we
moved to HarfBuzz as our main text shaper.  Now ligatures are almost
free for having, we just need motivated individuals to figure out the
user-facing front-end and write some simple Lisp.

Yes, the prettify-symbols-mode way is "easier".  Yes, there are many
packages out there which use that.  No, it isn't TRT, because it
causes you to be married to a certain edition of a certain font.  To
say nothing of the fact that static compositions, which underly
prettify-symbols-mode, don't support bidirectional scripts, and so are
from the get-go obsolete technology that we shouldn't embrace for
novel features.

The bottom line is that IMO we should take technology and future
developments into consideration when we decide how to implement core
features in Emacs.  That something can be easily done today is not
necessarily the only or even the main reason for doing that in core
that very way.

It is possible that "by popular demand" we will eventually use
something like those fonts, regardless of what I think, but I don't
think we should.

> P.S. ...and now I notice that this is pretty much the only communication medium I regularly use that doesn't
> automatically convert that smiley into an emoji... ...because I choose to have it off for this mailing list. 

Not sure why, the Emacs email agents are perfectly capable of
displaying smileys, certainly with our use of HarfBuzz today.