From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: storm@cua.dk (Kim F. Storm) Newsgroups: gmane.mail.mh-e.devel,gmane.emacs.devel Subject: Re: Shall we use etc/images more? Date: Tue, 13 Sep 2005 11:23:21 +0200 Message-ID: References: <14536.1126060623@olgas.newt.com> <20721.1126158478@olgas.newt.com> <873bo9vree.fsf@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 1126603826 31574 80.91.229.2 (13 Sep 2005 09:30:26 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 13 Sep 2005 09:30:26 +0000 (UTC) Cc: emacs-devel@gnu.org, mh-e-devel@lists.sourceforge.net Original-X-From: mh-e-devel-admin@lists.sourceforge.net Tue Sep 13 11:30:22 2005 Return-path: Original-Received: from lists-outbound.sourceforge.net ([66.35.250.225]) by ciao.gmane.org with esmtp (Exim 4.43) id 1EF71z-0006L0-90 for gmmd-mh-e-devel@m.gmane.org; Tue, 13 Sep 2005 11:24:47 +0200 Original-Received: from projects.sourceforge.net (sc8-sf-list1-b.sourceforge.net [10.3.1.7]) by sc8-sf-spam1.sourceforge.net (Postfix) with ESMTP id 84C1588693; Tue, 13 Sep 2005 02:24:46 -0700 (PDT) Original-Received: from sc8-sf-mx1-b.sourceforge.net ([10.3.1.91] helo=mail.sourceforge.net) by sc8-sf-list1.sourceforge.net with esmtp (Exim 4.30) id 1EF70z-0004cy-2R for mh-e-devel@lists.sourceforge.net; Tue, 13 Sep 2005 02:23:45 -0700 Original-Received: from pfepc.post.tele.dk ([195.41.46.237]) by mail.sourceforge.net with esmtp (Exim 4.44) id 1EF70w-0005X7-FX for mh-e-devel@lists.sourceforge.net; Tue, 13 Sep 2005 02:23:45 -0700 Original-Received: from kfs-l.imdomain.dk.cua.dk (unknown [80.165.4.124]) by pfepc.post.tele.dk (Postfix) with SMTP id 61D25262804; Tue, 13 Sep 2005 11:23:36 +0200 (CEST) Original-To: Bill Wohler In-Reply-To: <873bo9vree.fsf@olgas.newt.com> (Bill Wohler's message of "Mon, 12 Sep 2005 15:43:21 -0700") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) X-Spam-Score: 0.1 (/) 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 0.0 SF_CHICKENPOX_PERIOD BODY: Text interparsed with . 0.0 SF_CHICKENPOX_SLASH BODY: Text interparsed with / 0.0 SF_CHICKENPOX_MINUS BODY: Text interparsed with - 0.0 SF_CHICKENPOX_UNDERSCORE BODY: Text interparsed with _ 0.0 SF_CHICKENPOX_AT BODY: Text interparsed with @ 0.0 SF_CHICKENPOX_APOSTROPHE BODY: Text interparsed with ' -0.0 AWL AWL: From: address is in the auto white-list 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: This is a forum for the MH-E developers. Others are welcome to lurk. List-Post: List-Help: List-Subscribe: , List-Archive: X-Original-Date: Tue, 13 Sep 2005 11:23:21 +0200 Xref: news.gmane.org gmane.mail.mh-e.devel:10586 gmane.emacs.devel:42875 Archived-At: Bill Wohler writes: > One way to reorganize these--assuming that other packages haven't used > them yet--is to put them all into etc/images/mh-e. However, in the > interest of sharing images, I propose the following structure instead: I haven't looked at the actual icons, but from your described use, they sound more generally useful... > > etc/images/mail/alias -- adds the current sender to your alias file Add XX item to YY list/file. > etc/images/mail/rescan -- updates the message listing Refresh > etc/images/mail/show -- display the current message Display current ITEM > etc/images/mail/widen -- removes a view restriction Widen -- in general > Shortening the file names makes it easier to be 8.3 compliant, and is > essential in the images above. Does emacs support images on any of the 8.3 limited systems? > Three of the images could be generally useful and could be placed at > the top-level. It's possible I've overlooked other general images, so > feel free to comment. Maybe repack is too MH-specific and should be in > the MH-E directory? > > In the long term, I think we should modify find-image to use the > algorithm in mm-image-load-path instead of using just data-directory. That's a good suggestion. > That would make find-image more flexible by finding all relevant > etc/images directories so that mm-image-load-path (and MH-E's variant) > would no longer be necessary. To me it seems that having a generic image-load-path would be preferable!? It could be setup automatically to include subdirectories of etc/images/, just like load-path includes subdirectories of lisp/ > It could easily be made backward > compatible by stripping "images/" from a file spec. Yes. > If that's not in Emacs' interest, then I would suggest that instead of > (or in addition to) using data-directory, find-image should check a > new variable called image-directory (default: $EMACS_ROOT/etc/images) > which MH-E and Gnus can modify accordingly. That may be a good alternative to image-load-path, if we require using explicit subdirs in the image names, e.g. mail/reply. -- Kim F. Storm http://www.cua.dk ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf