From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Delayed loading of image libraries Date: 02 Jul 2004 10:11:52 +0200 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: <20040702085419.CF31.JMBARRANQUERO@wke.es> <20040702093521.CF34.JMBARRANQUERO@wke.es> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1088755938 27068 80.91.224.253 (2 Jul 2004 08:12:18 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 2 Jul 2004 08:12:18 +0000 (UTC) Cc: Andreas Schwab , emacs-devel@gnu.org, Miles Bader Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Fri Jul 02 10:12:11 2004 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1BgJ9X-0007aa-00 for ; Fri, 02 Jul 2004 10:12:11 +0200 Original-Received: from lists.gnu.org ([199.232.76.165]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BgJ9W-0001jI-00 for ; Fri, 02 Jul 2004 10:12:11 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BgJBK-0005Mn-R9 for emacs-devel@quimby.gnus.org; Fri, 02 Jul 2004 04:14:02 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1BgJBH-0005MQ-KV for emacs-devel@gnu.org; Fri, 02 Jul 2004 04:13:59 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1BgJBG-0005M6-GN for emacs-devel@gnu.org; Fri, 02 Jul 2004 04:13:59 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BgJBG-0005M3-82 for emacs-devel@gnu.org; Fri, 02 Jul 2004 04:13:58 -0400 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BgJ9Q-0008Cs-MU for emacs-devel@gnu.org; Fri, 02 Jul 2004 04:12:04 -0400 Original-Received: from localhost ([127.0.0.1] helo=lola.goethe.zz) by fencepost.gnu.org with esmtp (Exim 4.34) id 1BgJ9N-0006Yu-Pb; Fri, 02 Jul 2004 04:12:04 -0400 Original-To: Juanma Barranquero In-Reply-To: <20040702093521.CF34.JMBARRANQUERO@wke.es> Original-Lines: 45 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:25380 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:25380 Juanma Barranquero writes: > On 02 Jul 2004 09:10:55 +0200 > David Kastrup wrote: > > > It is > > not fine if an Emacs supporting PNG does not display a PNG. > > Sure. But currently, an Emacs supporting PNG *will* display a PNG if > the library is made available (either statically or dynamically). Miles > thinks (or so I understand) that the responsability of making the > library available rests on lookup_image_type. I believe the proper > thing to do is, at some point, calling `image-type-available-p'. The way I understand this, the responsibility of making the library available rests on the display code. If I put the stuff into a display property I saved just verbatim (without even taking a look at what image formats would be in it), then after restarting an Emacs session and restoring the display property, the PNG should display. No calls to lookup_image_type or image-type-available-p or whatever else by the user should be required. > > > After loading, Emacs *must* ask at a moment or other whether the > > > image type is available, mustn't it? > > > > How about when displaying it? > > And is not exactly that what I propose? If it is, I have failed to get it. It sounded to me like you were proposing that the user has to something before the image cn be displayed. > > Why should image-type-available-p have been called? > > Because, AFAICS, is the only documented way to know whether a given > image type is supported. What if a program does not care because it simply assumes that the configuration is correct? If a particular format is not supported, we currently just get boxes. That's ok. It is not ok if we just get boxes even _when_ a particular format is supported. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum