emacs-devel
[Top][All Lists]
Advanced

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

Re: Display of undisplayable characters: \U01F3A8 instead of diamond


From: Eli Zaretskii
Subject: Re: Display of undisplayable characters: \U01F3A8 instead of diamond
Date: Sat, 10 Sep 2022 18:40:26 +0300

> From: Emanuel Berg <incal@dataswamp.org>
> Date: Sat, 10 Sep 2022 17:19:44 +0200
> 
> Eli Zaretskii wrote:
> 
> >> If you store the result of running the program you don't
> >> need to execute the program again next time you need the
> >> result, instead you search for it and retrieve it, simple
> >> as that.
> >
> > That's what the current implementation does. It just stores
> > the results as a (much faster) program to be run at Emacs
> > startup time, that's all. AFAIU, your proposal is to store
> > just the ranges of problematic characters, which would
> > require to run, at Emacs startup time, another program to
> > read those ranges and issue the calls that the current
> > implementation embeds in the stored results.
> 
> Yes, of course, you need to be able to read the stored result.
> 
> But don't we have that already

Have what?

> and isn't that much less
> expensive than to compute that, optimized or not?
> 
> Also, isn't it easier for the user to have just a
> 
>   (setup-chars)
> 
> in the init which would
> 
>   1. look for stored data
>   2. (a) use it, if found
>   2. (b) compute it, if not found, and store it

What would be the purpose of adding a function for code that's
supposed to go into the user's init file?

> I don't see how that ever can be worse than generating code
> the user has to put into her/his file to compute the same
> thing every time?

The code must be added to the init file, once, anyway.

> A cache is better in terms of computing resources, and
> requires a less complicated interface for us humans.

It isn't a cache.



reply via email to

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