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: Richard M. Stallman
Subject: Re: Shall we use etc/images more?
Date: Tue, 13 Sep 2005 11:55:52 -0400

    I don't remember why reply2
    went into the mail directory, but we added the -2 suffix to avoid
    potential conflicts with Gnus.

If Gnus and MH-E both want an icon for replies, shouldn't they both
use the same one?

    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

This makes sense, except that having a subdirectory mh-e just to
contain one file is pointless.  It would be better to use
etc/images/mh-logo for that.

    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.

Conceptually, widen and rescan are not limited to mail,
so I think they ought to go at top level.

                          Maybe repack is too MH-specific and should be in
    the MH-E directory?

It's not worth having an mh-e directory just for that.

    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.

I think we should not do either of these; instead, we should do
what you've suggested here.

    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"

I agree.




reply via email to

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