1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
|
<!-- $Id: concus.html 600 2006-05-31 22:13:43Z wohler $ -->
<html>
<head>
<meta name="Author" content="Jerry Peek">
<title>Conflicts Between xmh and MH Customization: MH & nmh: Email for Users & Programmers</title>
<?$book = '..'?>
<link rel="stylesheet" href="<?=$book?>/mh.css" type="text/css">
</head>
<body>
<?
include "$book/mh.php";
includeHeader('resacc.html', 'usihea.html');
?>
<a name="index1"></a>
<h1>Conflicts Between xmh and MH Customization</h1>
<p>
Because <i>xmh</i> runs MH commands for you, many of the things
that you change in MH will affect <i>xmh</i>, too. Unless you look
at the <i>xmh</i> source code, it's not always easy to know
exactly what changes will affect <i>xmh</i>.
<p>
If you only use <i>xmh</i>, and never use MH, you don't need to
worry. Otherwise, read on...
<p>
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 <i>xmh</i>, too, but it's hard to change the
way that <i>xmh</i> uses MH commands. If you're good at UNIX shell
programming, though, check the Section
<a href="snoxmh.html#MakScr">Make a Front End Shell Script</a> for
ideas.
<p>
<a name="index2"></a>
<i>xmh</i> doesn't use MH commands for everything, though. Here's
a list of some things that <i>xmh</i> does for itself. Customizing
MH will not affect these <i>xmh</i> functions:
<ul>
<li>
Displaying messages in a main window or view window.
<li>
Editing messages in a composition window.
<li>
Selecting a sequence or folder.
<li>
Printing messages (unless you customize <i>xmh</i> to use MH
commands for printing).
</ul>
<a name="index3"></a> By now you know that each MH command looks
for default switches in the MH profile. If you use <i>xmh</i>, you
should understand how defaults like these affect it.
<!--[*** REFER TO 'snooping' SECTION ***] -->
<p>
If you run both MH and <i>xmh</i>, life can get confusing.
Changing command options for MH can affect <i>xmh</i> in weird
ways.
<p>
The best answer I've found is to make a separate MH profile file
for
<i>xmh</i> named <i>.xmh_profile</i>. Keep only entries for MH
functions that <i>xmh</i> will use, like the <tt>Path:</tt> entry.
Customize MH in your <i>.mh_profile</i> file.
<p>
To make <i>xmh</i> use your <i>.xmh_profile</i> file, store the
file's absolute pathname in the environment variable
named <i>MH</i>. Make sure that the environment variable is only
set while you're using
<i>xmh</i> -- otherwise, it will also affect your MH use while not
using
<i>xmh</i>. The easiest way to do this is by setting the
environment variable in your startup file (like <i>.xsession</i>).
If your startup file is read by the Bourne shell, use the
following line:
<pre>
MH=$HOME/.xmh_profile xmh <i>other_xmh_stuff</i> &
</pre>
If yours uses the C shell, there isn't a direct way -- but this
one is easy to understand:
<pre>
(setenv MH ~/.xmh_profile; xmh <i>other_xmh_stuff</i>)&
</pre>
<blockquote>
<b>NOTE:</b>
<i>xmh</i> Release 4 ignores the <tt>Path:</tt> entry that the
<i>MH</i> environment variable points to at startup time and
also when you use the <tt>Reply</tt> command.
<i>xmh</i> R4 looks for the <tt>Path:</tt> entry directly in
your
<i>.mh_profile</i> file, no matter where your <i>MH</i>
environment variable points it. <!-- Explain the ugly
workaround?: re-setting $HOME in xmh process only and making a
special MH profile in that directory... symlinking MH Mail
directory into that home directory. Hmmm. -->
</blockquote>
<?
includeFooter('$Date: 2006-05-31 15:13:43 -0700 (Wed, 31 May 2006) $',
'OReilly: 1991, 1992, 1995');
?>
</body>
</html>
|
