From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Juanma Barranquero Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Delayed loading of image libraries Date: Thu, 01 Jul 2004 11:30:49 +0200 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <20040701110632.415E.JMBARRANQUERO@wke.es> References: <20040630132923.BD10.JMBARRANQUERO@wke.es> <20040630154234.GB28623@fencepost> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1088674296 11929 80.91.224.253 (1 Jul 2004 09:31:36 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 1 Jul 2004 09:31:36 +0000 (UTC) Cc: Andreas Schwab , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Thu Jul 01 11:31:29 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 1Bfxuj-0002I4-00 for ; Thu, 01 Jul 2004 11:31:29 +0200 Original-Received: from lists.gnu.org ([199.232.76.165]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1Bfxuj-000487-00 for ; Thu, 01 Jul 2004 11:31:29 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BfxwT-0004MR-WA for emacs-devel@quimby.gnus.org; Thu, 01 Jul 2004 05:33:18 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1BfxwJ-0004Lx-Hk for emacs-devel@gnu.org; Thu, 01 Jul 2004 05:33:07 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1BfxwI-0004La-M8 for emacs-devel@gnu.org; Thu, 01 Jul 2004 05:33:07 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BfxwI-0004LU-Iw for emacs-devel@gnu.org; Thu, 01 Jul 2004 05:33:06 -0400 Original-Received: from [62.22.181.117] (helo=idefix.laley.net) by monty-python.gnu.org with esmtp (Exim 4.34) id 1Bfxu8-0006Gk-LC; Thu, 01 Jul 2004 05:30:52 -0400 Original-Received: from [172.17.221.23] (JMBARRANQUERO [172.17.221.23]) by idefix.laley.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id NZ3RGB05; Thu, 1 Jul 2004 11:29:19 +0200 Original-To: Miles Bader In-Reply-To: <20040630154234.GB28623@fencepost> X-Mailer: Becky! ver. 2.08.01 [en] 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:25349 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:25349 On Wed, 30 Jun 2004 11:42:34 -0400 Miles Bader wrote: > The result of `create-image' can be saved in a lisp file, and later loaded, > in which case the image will be displayed without `init-image-library' being > called from `image-type-available-p'y It can be loaded, sure, but can it be *displayed* without `image-type-available-p' being called? I'd say that's a bug. > I added a the call to make sure it > always gets called one way or another. The current situation is Not Good. Andreas has fixed your patch by passing it Qnil, which "works" in the sense that init-image-library doesn't fail. But: - It is now effectively a noop, because init-image-library'ing any image type from inside lookup_image_type will not load it. - Emacs on Windows crashes on certain kinds of image files (notably TIFFs). I think that's related to something I asked yesterday: lookup_image_type can return NULL, but at places its return value is just checked with xassert, which could be a noop, so it is posible to end creating image types with image->type == NULL. Why it is allowed? - We could make image-library-alist available from C and pass it to the call to init-image-library on lookup_image_type, but then, why make LIBRARIES an optional argument *at all*? At first, init-image-library didn't accept a second argument, it just used image-library-alist, but Kim suggested passing it as an argument so the user could manipulate it or supply an alternative loading list. So, IMHO: - We should make sure that image-type-available-p is called at the right places, so lookup_image_type does not need to call init-image-library. - We should guarantee that lookup_image_type is not going to return NULL (which doesn't make a lot of sense, as it is an internal function and we control whether it gets a valid image type or not). Juanma