Reiner Steib <[EMAIL PROTECTED]> writes:
> +(defun toolbarx-find-image (name)
> + "Return an image object from image on NAME, a string.
> +In Emacs, return a image descriptor from NAME and in XEmacs,
> +return a glyph.
>
> +Usually it should NAME does not contain a directory or an
> +extension. If the extension is omitted, `xpm', `xbm' and `pbm'
> +are tried. If the directory is omitted, `toolbarx-image-path' is
> +searched."
> + ;; `find-image' in Emacs 21 looks in `load-path' and `data-directory'. In
> + ;; Emacs 22, we have `image-load-path' which includes `load-path' and
> + ;; `data-directory'.
> + ;;
> + ;; If there's some API in XEmacs to find the images, we should use it
> + ;; instead of locate-library.
> + (or (when (fboundp 'find-image)
> + (let ((load-path toolbarx-image-path))
> + ;; We promised to consider toolbarx-image-path.
> + (find-image `((:type xpm :file ,(concat name ".xpm"))
> + (:type xbm :file ,(concat name ".xbm"))
> + (:type pbm :file ,(concat name ".pbm"))))))
> + ;; The following is for XEmacs and "name" _with_ extension. I doubt
> + ;; that the latter is useful, but the doc string says so.
find-image is an autoloaded Lisp function in `image'.
(find-image SPECS)
Find an image, choosing one of a list of image specifications.
And just _how_ is this autoloaded Lisp function going to be found when
load-path gets pointed elsewhere?
Reiner, please don't replace one hack with an even more ugly and
dangerous one. I propose that toolbarx-find-image just uses its old
method (but let us remove data-directory from toolbarx-image-path).
Only when that fails, does it call find-image.
That is reasonably clean and efficient, and it only depends on
find-image working.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
_______________________________________________
auctex-devel mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/auctex-devel
