Re: Any (brave :-) mew users?
mh-e in XEmacs is Chuck's baby. These changes are O.K. with me, but I
gave up on mh-e long, long ago.
It would be most useful if the glimpse code is as modular as possible
so it can be used with Gnus nnml. That's pretty much the last feature
in exmh not in Gnus I miss.
The /etc/passwd completion should be integrated outside of mail
modes (IMO). I am finding it increasingly irritating that I can
type `~us[TAB]' and have it expanded to `~username/' in the shell,
but XEmacs beeps.
Darryl Okahata <darrylo(a)sr.hp.com> writes:
SL Baur <steve(a)vmailer.xemacs.org> wrote:
> Hrvoje Niksic <hniksic(a)srce.hr> writes:
>
> >> > What is ``mew''? "Messaging in an Emacs world"
doesn't really tell
> >> > much.
>
> It is a mail reader that evolved from a programmer's distaste for the
> lack of development on mh-e.
I've got a ton of local changes/modifications to mh-e.
I've got no
plans to submit them to the mh-e maintainer (as I don't have the time to
get the legal paperwork done), but I could submit them to
xemacs-patches. Would anyone be interested in the following?
* Significant performance improvements by intelligent caching of
folder
contents (scans).
* Automatic generation of folder names when refiling messages, based
upon email addresses. For example, messages from "jdoe(a)foo.bar.com"
get a default folder name of "jdoe". Optional elisp functions can be
written to return default folder names, if the existing features are
insufficient. [ Other people have written similar features for mh-e,
but I believe my version has been around the longest, although poorly
publicized. ]
* Automatic alias completion, based upon MH aliases, sendmail
aliases,
and /etc/passwd. When entering email addresses at the "To:" prompt,
the TAB key can be used to do email address completion. [ Other
people have written similar features for mh-e, but I believe my
version has been around the longest, although poorly publicized. ]
* Automatic email address harvesting, for automatic email alias
generation. Whenever a message is viewed, the sender's name/address
can be automatically added to an internal database. The name/address
is then available for alias completion. Harvesting can be done upon
all folders, selected folders, or all folders but specified ones.
Inspired by exmh (but, for some inexplicable reason, exmh doesn't make
the address easily accessible for use in specifying "To:" &
"cc:"
addresses).
* Update mode line to turn off the "new mail" icon after
doing an "inc".
* Optional ability to visit new MH folders in new frames. Visiting
an
existing, but iconified, MH folder causes the frame to be
un-iconified.
* Optional ability to quit mh-e by iconifying the mh-e frame, instead
of
killing the mh-e buffers.
* Enhanced signature file processing. An optional elisp function can
be
specified to return a signature. This is useful for writing a
function that scans the draft to determine an appropriate signature.
I'm still hacking on my local mh-e. The next big feature that
I'm going
to add is an exmh-like interface to glimpse (this is a killer feature in
exmh).
However, the one possible downside to my changes is that the
mh-e
maintainer asked me to NOT begin any of my new mh-e functions with the
"mh-" prefix. For example, mh-e functions start with "mh-" (e.g.,
"mh-get-new-mail"). The maintainer asked me to not use the "mh-"
prefix, and so all of my changes have a "y-mh-" prefix, which makes the
code look odd, as functions begin with either "mh-" or "y-mh".