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

[Tim Cross <theophilusx@gmail.com>]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> 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?
>
Brilliant. However, I think you also need to wrap that communication
with the fsf.org service in a blockchain to secure the captured frames.
We may also be able to improve processing of the frame images using a
systolic array and uniform recurrence equations (URE)- I suspect this could
be slightly faster than the DNN. If the UREs are extended with
additional terms, we could even have an N-dimensional systolic array,
which could process each dimension on a separate core in parallel to
squeeze even more out of the system.