[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Shall we use etc/images more?
From: |
Kim F. Storm |
Subject: |
Re: Shall we use etc/images more? |
Date: |
Tue, 13 Sep 2005 11:23:21 +0200 |
User-agent: |
Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) |
Bill Wohler <address@hidden> 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 <address@hidden> http://www.cua.dk
- Re: Shall we use etc/images more?, (continued)
- Re: Shall we use etc/images more?, Chong Yidong, 2005/09/13
- Re: Shall we use etc/images more?, Kim F. Storm, 2005/09/14
- Re: Shall we use etc/images more?, Chong Yidong, 2005/09/14
- Re: Shall we use etc/images more?, Kim F. Storm, 2005/09/14
- Re: Shall we use etc/images more?, Richard M. Stallman, 2005/09/15
- Re: Shall we use etc/images more?, Katsumi Yamaoka, 2005/09/15
- Re: Shall we use etc/images more?, Bill Wohler, 2005/09/12
- Re: Shall we use etc/images more?,
Kim F. Storm <=
- Re: Shall we use etc/images more?, Eli Zaretskii, 2005/09/13
- Re: Shall we use etc/images more?, Bill Wohler, 2005/09/13
- Re: Shall we use etc/images more?, Mark D. Baushke, 2005/09/14
- Re: Shall we use etc/images more?, Richard M. Stallman, 2005/09/14
- Re: Shall we use etc/images more?, Bill Wohler, 2005/09/15
- Re: Shall we use etc/images more?, Peter S Galbraith, 2005/09/16
- Re: Shall we use etc/images more?, Bill Wohler, 2005/09/29
- Re: Shall we use etc/images more?, Bill Wohler, 2005/09/29
- Re: Shall we use etc/images more?, Chong Yidong, 2005/09/29
- Re: Shall we use etc/images more?, Richard M. Stallman, 2005/09/30