+</para>
+
+<para>
+
+</para>
+
+</sect1>
+
+<sect1 id="exec">
+<title>Executing functions </title>
+
+<para>
+Usage: <literal>exec</literal> <emphasis>function</emphasis> [ <emphasis>function</emphasis> ... ]
+</para>
+
+<para>
+This command can be used to execute any function. Functions are
+listed in the <link linkend="functions">functions</link>.
+``exec function'' is equivalent to ``push <function>''.
+</para>
+
+<para>
+
+</para>
+
+</sect1>
+
+<sect1 id="score-command">
+<title>Message Scoring </title>
+
+<para>
+Usage: <literal>score</literal> <emphasis>pattern</emphasis> <emphasis>value</emphasis>
+
+Usage: <literal>unscore</literal> <emphasis>pattern</emphasis> [ <emphasis>pattern</emphasis> ... ]
+</para>
+
+<para>
+In situations where you have to cope with a lot of emails, e.g.
+when you read many different mailing lists, and take part in
+discussions, it is always useful to have the important messages
+marked and the annoying messages or the ones that you aren't
+interested in deleted. For this purpose, mutt-ng features a
+mechanism called ``scoring''.
+</para>
+
+<para>
+When you use scoring, every message has a base score of 0. You
+can then use the <literal>score</literal> command to define patterns and a
+positive or negative value associated with it. When a pattern
+matches a message, the message's score will be raised or lowered by
+the amount of the value associated with the pattern.
+</para>
+
+<para>
+
+<screen>
+score "~f nion@muttng\.org" 50
+score "~f @sco\.com" -100
+</screen>
+
+</para>
+
+<para>
+If the pattern matches, it is also possible to set the score
+value of the current message to a certain value and then stop
+evaluation:
+</para>
+
+<para>
+
+<screen>
+score "~f santaclaus@northpole\.int" =666
+</screen>
+
+</para>
+
+<para>
+What is important to note is that negative score values will be
+rounded up to 0.
+</para>
+
+<para>
+To make scoring actually useful, the score must be applied in
+some way. That's what the <emphasis>score thresholds</emphasis> are for. Currently,
+there are three score thresholds:
+</para>
+
+<para>
+
+<itemizedlist>
+<listitem>
+
+<para>
+flag threshold: when a message has a score value equal or higher
+than the flag threshold, it will be flagged.
+
+</para>
+</listitem>
+<listitem>
+
+<para>
+read threshold: when a message has a score value equal or lower
+than the read threshold, it will be marked as read.
+
+</para>
+</listitem>
+<listitem>
+
+<para>
+delete threshold: when a message has a score value equal or
+lower than the delete threshold, it will be marked as deleted.
+
+</para>
+</listitem>
+
+</itemizedlist>
+
+</para>
+
+<para>
+These three thresholds can be set via the variables <link linkend="score-threshold-flag">score-threshold-flag</link>, <link linkend="score-threshold-read">score-threshold-read</link>, <link linkend="score-threshold-delete">score-threshold-delete</link> and. By
+default, <link linkend="score-threshold-read">score-threshold-read</link> and <link linkend="score-threshold-delete">score-threshold-delete</link> are set to
+<literal>-1</literal>, which means that in the default threshold configuration no
+message will ever get marked as read or deleted.
+</para>
+
+<para>
+Scoring gets especially interesting when combined with the <literal>color</literal> command
+and the <literal>˜n</literal> pattern:
+</para>
+
+<para>
+
+<screen>
+color index black yellow "~n 10-"
+color index red yellow "~n 100-"
+</screen>
+
+</para>
+
+<para>
+The rules above mark all messages with a score between 10 and 99
+with black and yellow, and messages with a score greater or equal
+100 with red and yellow. This might be unusual to you if you're used
+to e.g. slrn's scoring mechanism, but it is more flexible, as it
+visually marks different scores.
+</para>
+
+<para>
+
+</para>
+
+</sect1>
+
+<sect1 id="spam">
+<title>Spam detection </title>
+
+<para>
+Usage: <literal>spam</literal> <emphasis>pattern</emphasis> <emphasis>format</emphasis>
+
+Usage: <literal>nospam</literal> <emphasis>pattern</emphasis>
+</para>
+
+<para>
+Mutt-ng has generalized support for external spam-scoring filters.
+By defining your spam patterns with the <literal>spam</literal> and <literal>nospam</literal>
+commands, you can <emphasis>limit</emphasis>, <emphasis>search</emphasis>, and <emphasis>sort</emphasis> your
+mail based on its spam attributes, as determined by the external
+filter. You also can display the spam attributes in your index
+display using the <literal>%H</literal> selector in the <link linkend="index-format">index-format</link> variable. (Tip: try <literal>%?H?[%H] ?</literal>
+to display spam tags only when they are defined for a given message.)
+</para>
+
+<para>
+Your first step is to define your external filter's spam patterns using
+the <literal>spam</literal> command. <emphasis>pattern</emphasis> should be a regular expression
+that matches a header in a mail message. If any message in the mailbox
+matches this regular expression, it will receive a ``spam tag'' or
+``spam attribute'' (unless it also matches a <literal>nospam</literal> pattern -- see
+below.) The appearance of this attribute is entirely up to you, and is
+governed by the <emphasis>format</emphasis> parameter. <emphasis>format</emphasis> can be any static
+text, but it also can include back-references from the <emphasis>pattern</emphasis>
+expression. (A regular expression ``back-reference'' refers to a
+sub-expression contained within parentheses.) <literal>%1</literal> is replaced with
+the first back-reference in the regex, <literal>%2</literal> with the second, etc.
+</para>
+
+<para>
+If you're using multiple spam filters, a message can have more than
+one spam-related header. You can define <literal>spam</literal> patterns for each
+filter you use. If a message matches two or more of these patterns, and
+the $spam_separator variable is set to a string, then the
+message's spam tag will consist of all the <emphasis>format</emphasis> strings joined
+together, with the value of $spam_separator separating
+them.
+</para>
+
+<para>
+For example, suppose I use DCC, SpamAssassin, and PureMessage. I might
+define these spam settings:
+
+<screen>
+spam "X-DCC-.*-Metrics:.*(....)=many" "90+/DCC-%1"
+spam "X-Spam-Status: Yes" "90+/SA"
+spam "X-PerlMX-Spam: .*Probability=([0-9]+)%" "%1/PM"
+set spam_separator=", "
+</screen>
+
+</para>
+
+<para>
+If I then received a message that DCC registered with ``many'' hits
+under the ``Fuz2'' checksum, and that PureMessage registered with a
+97% probability of being spam, that message's spam tag would read
+<literal>90+/DCC-Fuz2, 97/PM</literal>. (The four characters before ``=many'' in a
+DCC report indicate the checksum used -- in this case, ``Fuz2''.)
+</para>
+
+<para>
+If the $spam_separator variable is unset, then each
+spam pattern match supersedes the previous one. Instead of getting
+joined <emphasis>format</emphasis> strings, you'll get only the last one to match.
+</para>
+
+<para>
+The spam tag is what will be displayed in the index when you use
+<literal>%H</literal> in the <literal>$index_format</literal> variable. It's also the
+string that the <literal>˜H</literal> pattern-matching expression matches against for
+<emphasis>search</emphasis> and <emphasis>limit</emphasis> functions. And it's what sorting by spam
+attribute will use as a sort key.
+</para>
+
+<para>
+That's a pretty complicated example, and most people's actual
+environments will have only one spam filter. The simpler your
+configuration, the more effective mutt can be, especially when it comes
+to sorting.
+</para>
+
+<para>
+Generally, when you sort by spam tag, mutt will sort <emphasis>lexically</emphasis> --
+that is, by ordering strings alphnumerically. However, if a spam tag
+begins with a number, mutt will sort numerically first, and lexically
+only when two numbers are equal in value. (This is like UNIX's
+<literal>sort -n</literal>.) A message with no spam attributes at all -- that is, one
+that didn't match <emphasis>any</emphasis> of your <literal>spam</literal> patterns -- is sorted at
+lowest priority. Numbers are sorted next, beginning with 0 and ranging
+upward. Finally, non-numeric strings are sorted, with ``a'' taking lower
+priority than ``z''. Clearly, in general, sorting by spam tags is most
+effective when you can coerce your filter to give you a raw number. But
+in case you can't, mutt can still do something useful.
+</para>
+
+<para>
+The <literal>nospam</literal> command can be used to write exceptions to <literal>spam</literal>
+patterns. If a header pattern matches something in a <literal>spam</literal> command,
+but you nonetheless do not want it to receive a spam tag, you can list a
+more precise pattern under a <literal>nospam</literal> command.
+</para>
+
+<para>
+If the <emphasis>pattern</emphasis> given to <literal>nospam</literal> is exactly the same as the
+<emphasis>pattern</emphasis> on an existing <literal>spam</literal> list entry, the effect will be to
+remove the entry from the spam list, instead of adding an exception.
+Likewise, if the <emphasis>pattern</emphasis> for a <literal>spam</literal> command matches an entry
+on the <literal>nospam</literal> list, that <literal>nospam</literal> entry will be removed. If the
+<emphasis>pattern</emphasis> for <literal>nospam</literal> is ``*'', <emphasis>all entries on both lists</emphasis>
+will be removed. This might be the default action if you use <literal>spam</literal>
+and <literal>nospam</literal> in conjunction with a <literal>folder-hook</literal>.
+</para>
+
+<para>
+You can have as many <literal>spam</literal> or <literal>nospam</literal> commands as you like.
+You can even do your own primitive spam detection within mutt -- for
+example, if you consider all mail from <literal>MAILER-DAEMON</literal> to be spam,
+you can use a <literal>spam</literal> command like this:
+</para>
+
+<para>
+
+<screen>
+spam "^From: .*MAILER-DAEMON" "999"
+</screen>
+
+</para>
+
+<para>
+
+</para>
+
+</sect1>
+
+<sect1 id="set">
+<title>Setting variables </title>
+
+<para>
+Usage: <literal>set</literal> [no|inv]<emphasis>variable</emphasis>[=<emphasis>value</emphasis>] [ <emphasis>variable</emphasis> ... ]
+
+Usage: <literal>toggle</literal> <emphasis>variable</emphasis> [<emphasis>variable</emphasis> ... ]
+
+Usage: <literal>unset</literal> <emphasis>variable</emphasis> [<emphasis>variable</emphasis> ... ]
+
+Usage: <literal>reset</literal> <emphasis>variable</emphasis> [<emphasis>variable</emphasis> ... ]
+</para>
+
+<para>
+This command is used to set (and unset) <link linkend="variables">variables</link>. There are four basic types of variables:
+boolean, number, string and quadoption. <emphasis>boolean</emphasis> variables can be
+<emphasis>set</emphasis> (true) or <emphasis>unset</emphasis> (false). <emphasis>number</emphasis> variables can be
+assigned a positive integer value.
+</para>
+
+<para>
+<emphasis>string</emphasis> variables consist of any number of printable characters.
+<emphasis>strings</emphasis> must be enclosed in quotes if they contain spaces or tabs. You
+may also use the ``C'' escape sequences <emphasis role="bold">\n</emphasis> and <emphasis role="bold">\t</emphasis> for
+newline and tab, respectively.
+</para>
+
+<para>
+<emphasis>quadoption</emphasis> variables are used to control whether or not to be prompted
+for certain actions, or to specify a default action. A value of <emphasis>yes</emphasis>
+will cause the action to be carried out automatically as if you had answered
+yes to the question. Similarly, a value of <emphasis>no</emphasis> will cause the the
+action to be carried out as if you had answered ``no.'' A value of
+<emphasis>ask-yes</emphasis> will cause a prompt with a default answer of ``yes'' and
+<emphasis>ask-no</emphasis> will provide a default answer of ``no.''
+</para>
+
+<para>
+Prefixing a variable with ``no'' will unset it. Example: <literal>set noaskbcc</literal>.
+</para>
+
+<para>
+For <emphasis>boolean</emphasis> variables, you may optionally prefix the variable name with
+<literal>inv</literal> to toggle the value (on or off). This is useful when writing
+macros. Example: <literal>set invsmart_wrap</literal>.
+</para>
+
+<para>
+The <literal>toggle</literal> command automatically prepends the <literal>inv</literal> prefix to all
+specified variables.
+</para>
+
+<para>
+The <literal>unset</literal> command automatically prepends the <literal>no</literal> prefix to all
+specified variables.
+</para>
+
+<para>
+Using the enter-command function in the <emphasis>index</emphasis> menu, you can query the
+value of a variable by prefixing the name of the variable with a question
+mark:
+</para>
+
+<para>
+
+<screen>
+set ?allow_8bit
+</screen>
+
+</para>
+
+<para>
+The question mark is actually only required for boolean and quadoption
+variables.
+</para>
+
+<para>
+The <literal>reset</literal> command resets all given variables to the compile time
+defaults (hopefully mentioned in this manual). If you use the command
+<literal>set</literal> and prefix the variable with ``&'' this has the same
+behavior as the reset command.
+</para>
+
+<para>
+With the <literal>reset</literal> command there exists the special variable ``all'',
+which allows you to reset all variables to their system defaults.
+</para>
+
+<para>
+
+</para>
+
+</sect1>
+
+<sect1 id="source">
+<title>Reading initialization commands from another file </title>
+
+<para>
+Usage: <literal>source</literal> <emphasis>filename</emphasis> [ <emphasis>filename</emphasis> ... ]
+</para>
+
+<para>
+This command allows the inclusion of initialization commands
+from other files. For example, I place all of my aliases in
+<literal>˜/.mail_aliases</literal> so that I can make my
+<literal>˜/.muttrc</literal> readable and keep my aliases private.
+</para>
+
+<para>
+If the filename begins with a tilde (``˜''), it will be expanded to the
+path of your home directory.
+</para>
+
+<para>
+If the filename ends with a vertical bar (|), then <emphasis>filename</emphasis> is
+considered to be an executable program from which to read input (eg.
+<literal>source ˜/bin/myscript|</literal>).
+</para>
+
+<para>
+
+</para>
+
+</sect1>
+
+<sect1 id="unhook">
+<title>Removing hooks </title>
+
+<para>
+Usage: <literal>unhook</literal> [ * | <emphasis>hook-type</emphasis> ]
+</para>
+
+<para>
+This command permits you to flush hooks you have previously defined.
+You can either remove all hooks by giving the ``*'' character as an
+argument, or you can remove all hooks of a specific type by saying
+something like <literal>unhook send-hook</literal>.
+</para>
+
+<para>
+
+</para>
+
+</sect1>
+
+<sect1 id="sect:sharingsetups">
+<title>Sharing Setups </title>
+
+<sect2>
+<title>Character Sets </title>
+
+<para>
+As users may run mutt-ng on different systems, the configuration
+must be maintained because it's likely that people want to use the
+setup everywhere they use mutt-ng. And mutt-ng tries to help where it
+can.
+</para>
+
+<para>
+To not produce conflicts with different character sets, mutt-ng
+allows users to specify in which character set their configuration
+files are encoded. Please note that while reading the configuration
+files, this is only respected after the corresponding declaration
+appears. It's advised to put the following at the very beginning of a
+users muttngrc:
+</para>
+
+<para>
+
+<screen>
+set config_charset = "..."
+</screen>
+
+</para>
+
+<para>
+and replacing the dots with the actual character set. To avoid
+problems while maintaining the setup, vim user's may want to use
+modelines as show in:
+</para>
+
+<para>
+
+<screen>
+# vim:fileencoding=...:
+</screen>
+
+</para>
+
+<para>
+while, again, replacing the dots with the appropriate name. This
+tells vim as which character set to read and save the file.
+</para>
+
+<para>
+
+</para>
+
+</sect2>
+
+<sect2>
+<title>Modularization </title>
+
+<para>
+``Modularization'' means to divide the setup into several files
+while sorting the options or commands by topic. Especially for
+longer setups (e.g. with many hooks), this helps maintaining it
+and solving trouble.
+</para>
+
+<para>
+When using separation, setups may be, as a whole or in
+fractions, shared over different systems.
+</para>
+
+<para>
+
+</para>
+
+</sect2>
+
+<sect2>
+<title>Conditional parts </title>
+
+<para>
+When using a configuration on different systems, the user may not
+always have influence on how mutt-ng is installed and which features
+it includes.
+</para>
+
+<para>
+To solve this, mutt-ng contain a feature based on the ``ifdef''
+patch written for mutt. Its basic syntax is:
+</para>
+
+<para>
+
+<screen>
+ifdef <item> <command>
+ifndef <item> <command>
+</screen>
+
+</para>
+
+<para>
+...whereby <literal><item></literal> can be one of:
+</para>
+
+<para>
+
+<itemizedlist>
+<listitem>
+
+<para>
+a function name
+
+</para>
+</listitem>
+<listitem>
+
+<para>
+a variable name
+
+</para>
+</listitem>
+<listitem>
+
+<para>
+a menu name
+
+</para>
+</listitem>
+<listitem>
+
+<para>
+a feature name