From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Emanuel Berg Newsgroups: gmane.emacs.devel Subject: Re: Display of undisplayable characters: \U01F3A8 instead of diamond Date: Sat, 10 Sep 2022 17:19:44 +0200 Message-ID: <87pmg3jlyn.fsf@dataswamp.org> References: <83czcakqd3.fsf@gnu.org> <87a67dxhfw.fsf@dataswamp.org> <875yi0wzx7.fsf@dataswamp.org> <834jxkk635.fsf@gnu.org> <878rmw8085.fsf@dataswamp.org> <83edwnj4fh.fsf@gnu.org> <87tu5j7tu1.fsf@dataswamp.org> <83a67bih0f.fsf@gnu.org> <83tu5jgvfy.fsf@gnu.org> <83sfl3gtah.fsf@gnu.org> <83fsh3ghn9.fsf@gnu.org> <87bkroub0v.fsf@dataswamp.org> <83r10kdd68.fsf@gnu.org> <87a6777seb.fsf@dataswamp.org> <83bkrnbux2.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="6035"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) To: emacs-devel@gnu.org Cancel-Lock: sha1:gIF1qiufwzMRhFVnDJoIun1qkX4= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Sep 10 17:38:29 2022 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oX2Yv-0001RB-12 for ged-emacs-devel@m.gmane-mx.org; Sat, 10 Sep 2022 17:38:29 +0200 Original-Received: from localhost ([::1]:55970 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oX2Yt-0006CD-UQ for ged-emacs-devel@m.gmane-mx.org; Sat, 10 Sep 2022 11:38:27 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57170) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oX2Gw-0007N9-K4 for emacs-devel@gnu.org; Sat, 10 Sep 2022 11:19:54 -0400 Original-Received: from ciao.gmane.io ([116.202.254.214]:43986) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oX2Gv-0005DO-0j for emacs-devel@gnu.org; Sat, 10 Sep 2022 11:19:54 -0400 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1oX2Gs-0008Lf-Pw for emacs-devel@gnu.org; Sat, 10 Sep 2022 17:19:50 +0200 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Mail-Copies-To: never Received-SPF: pass client-ip=116.202.254.214; envelope-from=ged-emacs-devel@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: -16 X-Spam_score: -1.7 X-Spam_bar: - X-Spam_report: (-1.7 / 5.0 requ) BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Sat, 10 Sep 2022 11:36:50 -0400 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:295133 Archived-At: Eli Zaretskii wrote: >>>> Situation: You want to do this, f(x) = y. >>>> >>>> Problem: f(x) is expensive to compute. >>>> >>>> Solution: Compute it ONCE, then store f = ((x y) ...) in >>>> a cache data file, so next time f(x) = y is needed, >>>> instead of computing f(x) again search the data file - >>>> search, which _isn't_ expensive. >>> >>> And I ask again: why does it matter whether you record >>> a program or its data >> >> 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, 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 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? A cache is better in terms of computing resources, and requires a less complicated interface for us humans. You don't agree? -- underground experts united https://dataswamp.org/~incal