From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/62279 Path: news.gmane.org!not-for-mail From: Katsumi Yamaoka Newsgroups: gmane.mail.mh-e.devel,gmane.emacs.gnus.general Subject: Re: gmm-image-load-path-for-library redux Date: Thu, 16 Mar 2006 16:24:37 +0900 Organization: Emacsen advocacy group Message-ID: References: <20403.1141690692@olgas.newt.com> <3861.1142268982@olgas.newt.com> <22907.1142318606@olgas.newt.com> <1183.1142359136@olgas.newt.com> <9172.1142473306@olgas.newt.com> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1142493922 11563 80.91.229.2 (16 Mar 2006 07:25:22 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 16 Mar 2006 07:25:22 +0000 (UTC) Cc: mh-e-devel@lists.sourceforge.net Original-X-From: mh-e-devel-admin@lists.sourceforge.net Thu Mar 16 08:25:20 2006 Return-path: Envelope-to: gmmd-mh-e-devel@m.gmane.org Original-Received: from lists-outbound.sourceforge.net ([66.35.250.225]) by ciao.gmane.org with esmtp (Exim 4.43) id 1FJmr8-0002up-IP for gmmd-mh-e-devel@m.gmane.org; Thu, 16 Mar 2006 08:25:10 +0100 Original-Received: from sc8-sf-list1-b.sourceforge.net (sc8-sf-list1-b.sourceforge.net [10.3.1.7]) by sc8-sf-spam1.sourceforge.net (Postfix) with ESMTP id CE0A5887A6; Wed, 15 Mar 2006 23:25:09 -0800 (PST) Original-Received: from sc8-sf-mx2-b.sourceforge.net ([10.3.1.92] helo=mail.sourceforge.net) by sc8-sf-list1.sourceforge.net with esmtp (Exim 4.30) id 1FJmqp-00055H-6S for mh-e-devel@lists.sourceforge.net; Wed, 15 Mar 2006 23:24:51 -0800 Original-Received: from washington.hostforweb.net ([66.225.201.13]) by mail.sourceforge.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44) id 1FJmqo-0007au-Ny for mh-e-devel@lists.sourceforge.net; Wed, 15 Mar 2006 23:24:51 -0800 Original-Received: from [205.234.185.198] (port=49850 helo=mail.jpl.org) by washington.hostforweb.net with esmtpa (Exim 4.52) id 1FJmqy-0005r2-G2; Thu, 16 Mar 2006 01:25:00 -0600 Original-To: ding@gnus.org X-Face: #kKnN,xUnmKia.'[pp`;Omh}odZK)?7wQSl"4o04=EixTF+V[""w~iNbM9ZL+.b*_CxUmFk B#Fu[*?MZZH@IkN:!"\w%I_zt>[$nm7nQosZ<3eu;B:$Q_:p!',P.c0-_Cy[dz4oIpw0ESA^D*1Lw= L&i*6&( User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) Cancel-Lock: sha1:d6+i69siGDIgu15ru/lrPSZh0vg= X-Hashcash: 1:20:060316:ding@gnus.org::rdG/oa+jE3ovJd+K:00003ZL+ X-Hashcash: 1:20:060316:mh-e-devel@lists.sourceforge.net::9zKiYWQ9fCf66sGU:000000000000000000000000000002VoO X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - washington.hostforweb.net X-AntiAbuse: Original Domain - lists.sourceforge.net X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jpl.org X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 1.0 (+) X-Spam-Report: Spam Filtering performed by sourceforge.net. See http://spamassassin.org/tag/ for more details. Report problems to http://sf.net/tracker/?func=add&group_id=1&atid=200001 1.0 FORGED_RCVD_HELO Received: contains a forged HELO Original-Sender: mh-e-devel-admin@lists.sourceforge.net Errors-To: mh-e-devel-admin@lists.sourceforge.net X-BeenThere: mh-e-devel@lists.sourceforge.net X-Mailman-Version: 2.0.9-sf.net Precedence: bulk List-Unsubscribe: , List-Id: Forum for the MH-E developers List-Post: List-Help: List-Subscribe: , List-Archive: X-Original-Date: Thu, 16 Mar 2006 16:24:37 +0900 Xref: news.gmane.org gmane.mail.mh-e.devel:12003 gmane.emacs.gnus.general:62279 Archived-At: 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