Re: [PATCH] Delayed loading of image libraries

[Juanma Barranquero]

On Thu, 01 Jul 2004 18:48:46 +0900
Miles Bader <address@hidden> wrote:

> Images are (currently) perfectly valid lisp values; if we don't want
> them to be readable and writable to files, we should make them an opaque
> type.

Reading and writing a lisp value (whether an image, or any other kind)
does not need image support.  *Processing* one of such values as an
image (to display it, ask questions about it, etc.) does need it.  At
that point, code should've asked whether the image type was available. 
I'm not sure why you do conflate reading/writing with using-as-an-image
(even if loading an image-representing lisp value ends up displaying it).

> But that seems like a stupid thing to do.  Just make the C code deal
> with the situation.  If my patch was wrong (though I admit, I still have
> no idea why

???

init-image-library has two mandatory arguments.  You didn't pass the
second one: the alist specifying where to find the dynamic libraries
supporting the desired image type.

>-- your discussion so far doesn't make much sense to me),

Why?  Lack of English skills, (absence of) clarity, vocabulary mismatch?

> fix it, but don't remove the functionality it adds.

I'm not trying to remove any functionality.  Honest.  I'm trying to know
where should it be implemented.

> [Note that reading and writing images to files (and displaying them in a
> new emacs instance, by just reading the file) worked fine before the
> changes that added Finit_image_library etc., so the bug I fixed is a
> regression.]

There's no doubt that it must be fixed.  Currently, it is not (my Emacs
crashes on displaying TIFFs).

I'll repeat one of my questions, not for you in particular, but for
anyone who knows: Why can lookup_image_type return NULL?

                                                                Juanma