Because xmh runs MH commands for you, many of the things that you change in MH will affect xmh, too. Unless you look at the xmh source code, it's not always easy to know exactly what changes will affect xmh.
If you only use xmh, and never use MH, you don't need to worry. Otherwise, read on...
Previous chapters show that you can change MH dramatically, adding new commands and changing the way existing commands work. You can change a lot about xmh, too, but it's hard to change the way that xmh uses MH commands. If you're good at UNIX shell programming, though, check the Section Make a Front End Shell Script for ideas.
xmh doesn't use MH commands for everything, though. Here's a list of some things that xmh does for itself. Customizing MH will not affect these xmh functions:
If you run both MH and xmh, life can get confusing. Changing command options for MH can affect xmh in weird ways.
The best answer I've found is to make a separate MH profile file for xmh named .xmh_profile. Keep only entries for MH functions that xmh will use, like the Path: entry. Customize MH in your .mh_profile file.
To make xmh use your .xmh_profile file, store the file's absolute pathname in the environment variable named MH. Make sure that the environment variable is only set while you're using xmh -- otherwise, it will also affect your MH use while not using xmh. The easiest way to do this is by setting the environment variable in your startup file (like .xsession). If your startup file is read by the Bourne shell, use the following line:
MH=$HOME/.xmh_profile xmh other_xmh_stuff &
If yours uses the C shell, there isn't a direct way -- but this
one is easy to understand:
(setenv MH ~/.xmh_profile; xmh other_xmh_stuff)&
NOTE: xmh Release 4 ignores the Path: entry that the MH environment variable points to at startup time and also when you use the Reply command. xmh R4 looks for the Path: entry directly in your .mh_profile file, no matter where your MH environment variable points it.