emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Shall we use etc/images more?


From: Bill Wohler
Subject: Re: Shall we use etc/images more?
Date: Mon, 12 Sep 2005 15:43:21 -0700
User-agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.4 (gnu/linux)

Bill Wohler <address@hidden> writes:

> I'll try to send out a proposal by early next week with the list of
> affected image files.

This email lists the images in use by the MH-E package today, explains
how they got there, and proposes new locations in etc/images for them.
At the end, I also suggest some code changes to image.el.


These are the (pbm and xpm) images the MH-E project has installed:

    toolbar/alias
    toolbar/execute
    toolbar/highlight
    toolbar/mh-logo
    toolbar/page-down
    toolbar/refile
    toolbar/repack
    toolbar/reply-all
    toolbar/reply-from
    toolbar/reply-to
    toolbar/rescan
    toolbar/show
    toolbar/widen
    mail/reply2

They are in the toolbar directory since the images were added before
MH-E had its own directory, and were put there instead of the mail
directory at RMSs urging. I think the mail-specific images lack a
mail- prefix because of 8.3 restrictions. I don't remember why reply2
went into the mail directory, but we added the -2 suffix to avoid
potential conflicts with Gnus.

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:
    
    etc/images/mail/alias -- adds the current sender to your alias file
    etc/images/mail/refile -- files the message(s)
    etc/images/mail/repack -- renumbers the messages, removing gaps
    etc/images/mail/reply -- different flavors of replies
    etc/images/mail/reply-all
    etc/images/mail/reply-from
    etc/images/mail/reply-to
    etc/images/mail/rescan -- updates the message listing
    etc/images/mail/show -- display the current message
    etc/images/mail/widen -- removes a view restriction
    etc/images/mh-e/mh-logo
    etc/images/execute -- could be used by the dired `x' command
    etc/images/highlight -- used to add a persistent mark
    etc/images/page-down

Instead of putting all of the images in a single directory and using
the convention of preceding an image name with mail-, for example, it
would be preferable to use the directory structure for this purpose.
Shortening the file names makes it easier to be 8.3 compliant, and is
essential in the images above.

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?

Gnus uses mm-image-load-path to add etc/images/gnus to the load-path
if it finds an ../etc/images/gnus directory relative to another
directory in the load-path. We'd have to do something like that as
well since we the user can run a version of MH-E outside of the Emacs
tree. Unfortunately, the function adds "gnus" by default so in the
short term we'd create our own version.

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 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. It could easily be made backward
compatible by stripping "images/" from a file spec.

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.

Gnus adds etc/images/gnus to the load-path so that it can refer to the
images directly like "exit-gnus" instead of "gnus/exit-gnus". I think
I'd prefer to specify the images explicitly as in "execute" or
"mail/reply". This would make the code impervious to future changes of
find-image and I think the slightly longer names would improve
maintenance by making it easier to find the images. It also eliminates
name collisions that we have in the current scheme.

Thoughts? Questions? Comments?

-- 
Bill Wohler <address@hidden>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian!
If you're passed on the right, you're in the wrong lane.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]