all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Chong Yidong <cyd@gnu.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: lekktu@gmail.com, jwalt@garni.ch, 12463@debbugs.gnu.org
Subject: bug#12463: 24.2; pos-visible-in-window-p gets slower over time
Date: Fri, 21 Sep 2012 17:24:17 +0800	[thread overview]
Message-ID: <87d31fd8zi.fsf@gnu.org> (raw)
In-Reply-To: <83pq5fyglu.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 21 Sep 2012 10:34:05 +0300")

Eli Zaretskii <eliz@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.





  reply	other threads:[~2012-09-21  9:24 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-17 23:51 bug#12463: 24.2; pos-visible-in-window-p gets slower over time Jörg Walter
2012-09-18  7:46 ` Eli Zaretskii
2012-09-18  9:46   ` Jörg Walter
2012-09-18 10:23     ` Eli Zaretskii
2012-09-18 15:05     ` Matt Lundin
2012-09-18 16:24       ` Eli Zaretskii
2012-09-18 15:17   ` Chong Yidong
2012-09-18 16:18     ` Jörg Walter
2012-09-20 23:22       ` Juanma Barranquero
2012-09-21  3:52         ` Chong Yidong
2012-09-21  5:42           ` Chong Yidong
2012-09-21  7:34             ` Eli Zaretskii
2012-09-21  9:24               ` Chong Yidong [this message]
2012-09-21 10:47                 ` Juanma Barranquero
2012-09-21 12:33                   ` Eli Zaretskii
2012-09-21 16:38                     ` Stefan Monnier
2012-09-21 16:58                       ` Eli Zaretskii
2012-09-21 20:34                         ` Stefan Monnier
2012-09-22  6:58                           ` Eli Zaretskii
2012-09-22 20:20                             ` Stefan Monnier
2012-09-22 20:31                               ` Juanma Barranquero
2012-09-23  9:17                                 ` Chong Yidong
2012-09-23  3:50                               ` Eli Zaretskii
2012-09-21  9:10             ` Juanma Barranquero
2012-09-21 10:01               ` Chong Yidong
2012-09-21 17:03                 ` Eli Zaretskii
2012-09-21 17:07                   ` Juanma Barranquero
2012-09-21 17:45                     ` Eli Zaretskii
2012-09-22  1:23                       ` Chong Yidong
2012-09-22  8:36                         ` Eli Zaretskii
2012-09-22 11:05                           ` Chong Yidong
2012-09-22 11:18                             ` Eli Zaretskii
2012-09-22 14:14                               ` Chong Yidong
2012-09-22 14:25                                 ` Eli Zaretskii
2012-09-22 19:20                                 ` Juanma Barranquero
2012-09-22 19:46                                   ` Eli Zaretskii
2012-09-22 19:53                                     ` Juanma Barranquero
2012-09-23  3:48                                       ` Eli Zaretskii
2012-09-21  6:58           ` Eli Zaretskii
2012-09-21  8:36           ` Juanma Barranquero
2012-09-21  9:11             ` Chong Yidong
2012-09-21  9:17               ` Juanma Barranquero
2012-09-18 16:19     ` Eli Zaretskii
2012-09-18 16:26       ` Jörg Walter
2012-09-18 17:19         ` Eli Zaretskii
2012-09-18 17:31           ` Juanma Barranquero
2012-09-18 20:00             ` Eli Zaretskii
2012-09-19  2:31               ` Juanma Barranquero
2012-09-19  2:57                 ` Eli Zaretskii
2012-09-19  3:03                   ` Juanma Barranquero

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87d31fd8zi.fsf@gnu.org \
    --to=cyd@gnu.org \
    --cc=12463@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    --cc=jwalt@garni.ch \
    --cc=lekktu@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.