GNU bug report logs - #12463
24.2; pos-visible-in-window-p gets slower over time

Previous Next

Full log

Message #82 received at 12463 <at> debbugs.gnu.org (full text, mbox):

From: Chong Yidong <cyd <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: lekktu <at> gmail.com, jwalt <at> garni.ch, 12463 <at> debbugs.gnu.org
Subject: Re: bug#12463: 24.2; pos-visible-in-window-p gets slower over time
Date: Fri, 21 Sep 2012 17:24:17 +0800

Eli Zaretskii <eliz <at> gnu.org> writes:

>> ! #ifdef HAVE_NTGUI
>> !       /* If we failed to load the library before, don't try again.  */
>> !       Lisp_Object tested = Fassq (target_type, Vlibrary_cache);
>> !       if (CONSP (tested) && NILP (XCDR (tested)))
>> ! 	type_valid = 0;
>> !       else
>> ! #endif
>> ! 	{
>> ! 	  /* If the load failed, avoid trying again.  */
>> ! 	  type_valid = (*type->init)(libraries);
>> ! 	  CACHE_IMAGE_TYPE (target_type, type_valid);
>> ! 	}
>> !     }
>
> What will happen if 'tested' is not a cons cell?

If `tested' is not a cons cell, it must be nil, and the code proceeds
with the library initialization.

>>   of `dynamic-library-alist', which see).  */)
>>     (Lisp_Object type, Lisp_Object libraries)
>>   {
>> !   struct image_type *p = lookup_image_type (type, libraries);
>> !   return p ? *p->type : Qnil;
>> ! }
>
> This changes the return value of init-image-library; is there a good
> reason for not returning Qt here instead of the type symbol?

No good reason; we could return Qt here.

>> ! /* Look up image type SYMBOL, and return a pointer to its image_type
>> !    structure.  Value is null if SYMBOL is not a known image type.  */
>
> Again, LIBRARIES is not documented.  Also, I believe we use NULL in
> caps elsewhere.  And finally, the argument is called TYPE, not SYMBOL.

Thanks.

>> ! static struct image_type *
>> ! lookup_image_type (Lisp_Object type, Lisp_Object libraries)
>> ! {
>> !   if (NILP (libraries))
>> !     libraries = Vdynamic_library_alist;
>
> I can't say I like this "default".  Why not always call
> lookup_image_type with Vdynamic_library_alist?  For that matter, why
> not make lookup_image_type always use Vdynamic_library_alist without
> passing it through the call parameters?

This is simply following the existing practice of Finit_image_library.
I don't know why that function accepts a LIBRARIES argument, rather than
just making callers bind Vdynamic_library_alist.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.