exmh.README
Last modified: Fri Jan 14 13:51:31 PST 1994
exmh version: 1.2
Brent Welch, welch@parc.xerox.com

exmh is a TCL/TK based interface to the MH mail system.
All you need is wish (3.6 is best, >= 3.2 should work) and MH (I have 6.7.2).

Please read through all of this, thanks, especially
the part at the end about the TK send command.

See exmh.CHANGES for what's new in this version.

Note that the tar file now unpacks in a subdirectory, ./exmh-1.2,
and the default for the library directory also has the version number.

New goodies in misc - check misc/README

There is a bug in TK >= 3.3 in the text widget that exmh manages to tickle.
This causes a core dump in wish.  However, there is a patch that fixes
this, and it is in the misc/tkText.patch file.  If you have TK 3.6 and
have applied Ousterhout's first patch, then you are ok.

Thanks go to Ed Oskiewicz for inspiring me with an initial verison,
which is much modified by now.  Thanks also go to many beta testers
that put up with buggy versions and suggested many features that
are now part of exmh.  Feature requests that come with code diffs
to implement them are especially nice.  Honorable mention goes to
John LoVerso who has contributed the most.

As well as providing the usual layer on top of MH commands, exmh
has a number of other features:

    MIME support!  Displays richtext and enriched directly.  Parses
    multipart messages.  Displays hot buttons that invoke external viewers
    (metamail) for things not directly supported.  Built-in editor allows
    simple composition of text/enriched format.

    Color feedback in the scan listing so you can easily identify
    unseen messages (blue), the current message (red), deleted
    messages (gray background), and moved messages (yellow background).
    Xresources control these color choices.

    Monochrome displays highlight unseen messages with underline,
    current message in reverse video, deleted messages with cross-hatching
    background, and moved messages with stippled background.

    A folder display with one label per folder.  Color highlights
    indicate the current folder (red), folders with unseen messages
    in them (blue), and the target folder for moves (yellow background).
    Nested folders are highlighted by a shadow box.  A cache of
    recently visted folder buttons is also maintained.  Monochrome
    highlights are reverse video for the current folder, bold box
    for folders with unseen messages, and stippled box for the
    target of move operations.

    Clever scan caching.  MH users know that scan is slow, so
    exmh tries hard to cache the current state of the folder to
    avoid scanning.  Moves and deletes within exmh do not
    invalidate the cache, and background incs that add new messages
    are handled by merging them into the scan listing.  The
    scan cache is compatible with xmh.

    Facesaver bitmap display.  If you have a facesaver database
    on your system, exmh displays the bitmap face of the person
    that sent the current message (or their organization).
    Otherwise, it just displays a boring EXMH logo.

    Background inc.  You can set exmh to run inc periodically,
    or just to periodically count up the messages in your mail spool file.
    (Depends on proper TK send functioning.  See notes below.)

    Various inc styles.  Exmh knows about three styles of inc usage:
    Inc from your spool file to your inbox folder.
    Inc from your spool file or POP host to a set of dropboxes as specified
    by your ~/.xmhcheck file.
    Inc from your spool file directly into folders.  Exmh can run the MH
    filtering program (slocal) for you, or you can let an external agent
    presort mail into folders for you.

    Searching over folder listing and message body.

    A dialog-box interface to MH pick.

    A simple editor with emacs-like bindings is provided by default.
    It has an interface that lets you tweak key bindings.

    Editor interface.  You can hook up exmh to TCL based-editors
    like mxedit quite easily.  A script is also provided, exmh-async,
    for using terminal based editors like vi.  The emacsclient.README
    file has hand-wavy instructions for using emacsclient to talk
    to an emacs server.

    User preferences.  You can tune exmh through a dialog box.  The settings
    are saved in an Xresource-style file named .exmh-defaults.  You can
    also put font and color resource specifications in this file, plus
    there are a few random parameters not exposed via preferences.

    User hacking support.  A user library of TCL routines is supported.
    The main implementation is chopped up into many smallish modules.
    So, you can modify a copy of some module to put your favorite mail
    reader hack in without affecting others (or convincing me to put
    it into the main line).  There are also a number of places where
    hook procedures are used so you can refine the behavior of things
    like composing a reply message.  Details in the man page.

INSTALLATION

Installation is done via the exmh.install script.  Invoke it as:

    wish -f exmh.install

This puts up a dialog box that lets you patch various file system
specific pathnames and enable or disable features that your
system cannot support (e.g., facesaver, sound).  You can test
out exmh via this dialog before installing it.

Upon startup, exmh.install looks around for .exmhinstall files from
previous installations.  It will ask you which one you want to use,
unless there is already one in the current directory.

In the install dialog, the "Script Library" and the "Install lib directory"
are usually the same place.  The script library is the run-time value
of the library directory, while the install lib directory is the
install-time value.  The Test button now automatically changes the
run-time value to "./lib" in order to test before installing.  So,
the only reason for the distinction between install-time and run-time
is for AFS environments where writable and read-only volumes might
have different names.

Remember to choose a script library directory that exmh can take up
all for itself.  The install is *not* smart enough to make an exmh
subdirectory in a common lib dir (e.g., /usr/local/lib).

After you set things up in the dialog box, then hit some buttons:

1. Patch - to apply site-dependent patches to exmh.
    The configuration is saved into a .exmhinstall file.
2. TclIndex - to compute the auto-load library index.
3. Test - to run the patched script.
4. Verify - to see what the Install will do.
5. Install - to install exmh.

If the install fails to work gracefully on your system, let me know!
One common error is to get a complaint about the procedure "Exmh" not
being defined.  This happens when the value of the script library
is not correct.

VERY IMPORTANT. PLEASE READ. SOURCE OF MANY PROBLEMS. READ THIS HERE :-)

exmh depends on the TK send facility for its background processing.
With TK 3.3, send now uses xauthority mechanisms by default, unless
you compile TK with -DNO_SECURITY.  A manifestation of problems are
that background processing doesn't work: new messages are not scanned
into the current folder, the flag icon doesn't behave, and so on.
Similarly, use of the exmh-async wrapper script also fails.
If you cannot recompile wish, then the trick is to get your X server process
started with the right incantation.

You can easily test send (and my installation process should have...)
Just run wish, and type in the following command to it:

send exmh {Exmh_Status "Hello world"}

Obviously, make sure exmh is running first.

If you get an error, you need to recompile the TK library, or learn how
to start up the X server so it does the right Xauthentication stuff.

Here is one example, for SunOS openwindows.  This is an excerpt from
a .xerverrc file:

    if [ ! \( -d $HOME -a -w $HOME \) ]; then
      echo "Warning: Can't write X authority file" 1>&2 ;
      auth_args=""
    else
      authfname=$HOME/.xnews.`uname -n`$DISPLAY
      ${OPENWINHOME}/lib/mkcookie $authfname -auth magic-cookie
      auth_args="-auth $authfname"
    fi ;
    ${OPENWINHOME}/bin/xnews $auth_args $server_args $xnews_config_args ;;

The general picture of whats going on is this:
1) some program generates a magic cookie (arbitrary string) and writes
this to a file.
2) The name of this file is passed to the X server
3) The X server writes an entry for the DISPLAY into your ~/.Xauthority
file.
4) Xlib reads ~/.Xauthority when you create a window, and passes the
cookie value back to the X server.

If you have the xauth program and your server doesn't like to be told about
the intermediate file, then you can use xauth to write into the
~/.Xauthority file for you, and apparenty the right thing will happen.
If this sounds vague, it is.  For precise details, do some experimentation
or ask your local X guru.  If you come up with particular solutions,
feel free to post them to comp.lang.tcl so other folks with similar
configurations can learn how to do the right thing as well.

See also misc/Xauthority for similar info.

CONCLUDING REMARKS

If you end up using exmh on a regular basis, also let me know!
If I can tell my managers that there are N users of my mail
reader, there is a greater chance I'll have time to hack up
more tools in the future (and still get paid).

Finally, please take time to read the man page before asking too many
questions.  If exmh gets an internal error it will display a dialog
box with a TCL trace back and a User Input: area.  You can type short
note into that area, and then hit the "send to exmhbugs" button in
order to file a bug report.  I'll consider feature requests, but
basically I'd appreciate it if you'd code up your feature and
send me some diffs or just the whole file that is affected.
----------------------------------
	Brent Welch	Xerox-PARC
	welch@parc.xerox.com