emacs-devel
[Top][All Lists]
Advanced

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

Re: scratch/emoji vs emacs that maybe canʼt display emojis


From: Stefan Monnier
Subject: Re: scratch/emoji vs emacs that maybe canʼt display emojis
Date: Sun, 07 Nov 2021 17:31:17 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Lars Ingebrigtsen [2021-11-07 21:48:50] wrote:
> Eli Zaretskii <eliz@gnu.org> writes:
>> We could perhaps introduce some heuristics based on the first
>> character of the composition, for example that the result of composing
>> CH cannot be narrower than CH itself.  But that will only work up to a
>> point.  E.g., AFAIR some Emoji has the width of 1.
> Perhaps it depends on the font, too?  I'm pretty sure that none of the
> composed emojis in Noto Color Emoji have a width of 1, but that's
> basically the only emoji font I've been futzing around with.
>> And then there are terminal emulators that do some preposterous stuff,
>> assuming that their tail can wag the dog.  See PROBLEMS and search for
>> "kitty", for some fun.
> Heh.

How 'bout we add a simple little hack to Emacs: when running in a tty
and we need to display something like an emoji, use a local DNN (deep
neural network) to guess the width that will be used for the char, then
contact an fsf.org service that connects to a nearby camera, grabs a few
frames, passes them to text recognition DNN to estimate the number of
text columns that the terminal used when displaying this char, send the
result back to Emacs and if the initial guess was wrong adjust the
local DNN and redisplay.

WDYT?


        Stefan


PS: OK, we could replace the fsf.org service + remote DNN with say, the
user's brain, but what would be the fun in that?




reply via email to

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