Re: Shall we use etc/images more?

[Kim F. Storm]

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