Re: gmm-image-load-path-for-library redux

[Katsumi Yamaoka <yamaoka@jpl.org>]

My conclusion is that your new code is wonderful. :)

>>>>> In <9172.1142473306@olgas.newt.com> Bill Wohler wrote:

>>       ;; Check for another directory that is specified in
>>       ;; image-load-path and preferred than image-directory.
>>       ((and image-directory
>>             (boundp 'image-load-path))
>>        (let ((image-load-path
>>               (butlast
>>                (symbol-value 'image-load-path)
>>                (length (member (file-name-as-directory image-directory)
>>                                (mapcar
>>                                 (lambda (dir)
>>                                   (if (stringp dir)
>>                                       (file-name-as-directory dir)
>>                                     dir))
>>                                 (symbol-value 'image-load-path)))))))
>>          (setq dir (image-search-load-path image))))

> Oh boy, that took me about an hour to figure out ;-).

I might have had to fill up that section with thorough comments.
Sorry.

> Assuming I've understood correctly, I think I see a couple of
> problems.

> I don't see how (butlast) can be right. That code is stripping away
> the directory found in .../etc/images *plus* all of the directories
> that follow it which could include the user's directory.

I assumed users will add preferred directories to the beginning
of the list, and I also thought that the directory
"gnus/../../etc/images" (or "gnus/../etc/images") in which an
image has already been found and the directories following it
should be ignored.  Even if an image exists in one of
directories which are stripped from the list, we can ignore it
since the directory is not supposed to be preferred than
"gnus/../../etc/images" (or "gnus/../etc/images").  In
connection with this, I didn't expand variable symbols which are
contained in `image-load-path' into lists since I assumed users
won't add image directories to `load-path' in the system that
provides `image-load-path'.

> Most likely .../etc/images won't be in image-load-path at all,

No, it won't be.  By Emacs' default, Gnus will be installed
in "${PREFIX}/share/emacs/${VERSION}/lisp/gnus", images will be
in "${PREFIX}/share/emacs/${VERSION}/etc/images", and the
default value of `image-load-path' will be:

("${PREFIX}/share/emacs/${VERSION}/etc/images/" data-directory load-path)

In addition, if Gnus is installed separately, it will be
installed in "${PREFIX}/share/emacs/site-lisp/gnus" and
"${PREFIX}/share/emacs/etc/images" by default...

Oops, I noticed another problem right now.  In the later case,
the code I revised will choose the first element of
`image-load-path', not the one installed with Gnus separately.
After all, the variable like `gnus-image-directory' (which
defaults to "gnus/../../etc/images" or "gnus/../etc/images")
might be necessary to respect user's taste.

(I didn't notice this until now since I installed Gnus in
"${PREFIX}/share/emacs/${VERSION}/site-lisp/gnus" and
"${PREFIX}/share/emacs/etc/images".)

> so the last directory in image-load-path will be stripped (which
> could be the user's directory if they preferred to use the system
> images but provided images as a fall-back).

If "gnus/../../etc/images" (or "gnus/../etc/images") is not in
`image-load-path', nothing will be stripped because:

(eq image-load-path (butlast image-load-path 0)) => t

> I'm not quite sure of the whole point of that exercise anyway. Why not
> just call (image-search-load-path image)?

> But still, this isn't correct. If the user does *not* have a preferred
> version, and you're running an external package, you'd prefer the
> .../etc/images version over the one already in image-load-path. But this
> code would give you the directory already in image-load-path.

Exactly.  This is just what I noticed now.

> A minor point, but why use (symbol-value 'image-load-path)? Why not just
> the simpler and clearer image-load-path?

(I mentioned it in my last message as:
The purpose is just the same as (defvar image-load-path) you
did; i.e., avoiding a compiler warning that Emacs 21 issues.)

> What I think might work is that we call (image-search-load-path image)
> and use it instead of .../etc/images if and only if it isn't the system
> image directory. The system image directory is (concat data-directory
> "images"), right?

I believe it.

> Here is a reworked function that seems to do what everybody wants (and
> hopefully doesn't take an hour to understand ;-). What do you think?

That's skillful!  But it was easy to understand.  It also solves
the problem I mentioned above (the case that Gnus is installed
separately with the default configuration).  Could you install
it in Emacs?

Thanks and thanks in advance.


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642