Lines whose first nonblank character is # or ;, or which have no
nonblank characters, are comments, and are completely ignored.  Note
that # and ; characters elsewhere are not special.

There are multiple kinds of constructs the config file can contain:
connection definitions, filter definitions, and context definitions.
Constructs cannot be interwoven; an occurrence of a line beginning a
construct ends any preceding construct.  There can also be
configuration lines that are not part of any construct but which
control startup things, such as which context is initially active.

When parsing these lines, " ", ' ', and \ get special treatment.  \
quotes the next character, and " " and ' ' quote everything inside
them.  Inside " " or ' ', \ can be used to quote even the closing
delimiter.  In particular, these can be used to get whitespace into an
argument.  Arguments are separated by (unquoted) whitespace.

However, the semantics of \ followed by a letter or digit may change in
the future.

However, some commands take an argument which is special, with no
quoting or delimiters; such an argument is always the last argument on
its command and is called a `trailing-text' argument.  Such an argument
begins with the first non-whitespace character following whatever is
before it and extends to the end of the line; if there is nothing
there, the trailing-text argument is zero length.

A connection definition consists of one line:

conn NAME SERVER NICK [OPTIONS...]

	[OPTIONS...] is zero or more of:
		-user USERNAME
		-host HOSTNAME
		-name FULLNAME
			These override the defaults, which are $USER,
			`hostname`, and your passwd file entry's gecos
			name.
		-once
			If the connection drops, murk normally tries to
			reestablish it.  -once suppresses this.

	The first arg (NAME) is not anything visible in the protocol;
	it is a short name for this connection, used to refer to it
	from elsewhere.  Multiple connections may have the same short
	name, but it is then not possible to distinguish between them
	in filters and tells - filters treat them all identically and
	tells send to all of them.

A filter definition consists of a `filter' line, then zero or more
`match' lines.

filter NAME ACTION
	This introduces the filter.  NAME is a short name for the
	filter, used to refer to it elsewhere; ACTION is a filtering
	action, which controls what happens if none of the action lines
	match (this includes the case where there are no action lines
	at all).  See below for what ACTION can be.

match NESTING ACTION CRITERIA
	These configure what lines a filter matches.  NESTING consists
	of zero or more > signs, optionally intermixed with whitespace.
	The number of >s indicates the nesting of the match.  The
	paradigm is that a filter has a list of match lines, each of
	which potentially has its own list of sub-lines.  A line is
	matched against the list, in order, until some line matches.
	Then, its sub-lines, if any, are matched.  The action of the
	last match line which matches controls whether the context sees
	the output.

	The ACTION specifies what happens if no sub-match matches
	(including the case where there are no sub-matches at all); see
	below for more.

	The CRITERIA consist of clauses, all of which must be satisfied
	for this line to match.  If there are no clauses, the line
	always matches.

	type=TYPE
		Matches if the line type matches the regex TYPE.  A
		line type is either a word such as JOIN or NOTICE or a
		three-digit code.

	conn=NAME
		Matches if the line came from a connection whose short
		name matches the regex NAME.

	from=PATTERN
		Matches if the line's prefix matches the regex PATTERN.
		A line with no prefix is treated as having a
		zero-length string for a prefix.  The leading : on the
		prefix is always stripped before matching.

	content=PATTERN
		Matches if the line's content matches PATTERN.

	use=NAME
		Runs the filter named NAME.  This clause matches iff
		that filter accepts the line.

	fail=NAME
		Runs the filter named NAME.  This clause matches iff
		that filter does not accept the line.

It is an error for a filter to refer to itself, even indirectly, via
use= or fail= clauses; if, while evaluating a filter, a use= or fail=
clause is encountered naming that same filter, a run-time error occurs.

ACTIONs, such as are used on filter and match lines, specify either
acceptance or rejection.  Because actions are used in multiple places,
there are multiple keywords supported for each action, so that it is
easy to pick one that makes linguistic sense.

	Acceptance: accept allow match pass yes
	Rejection: reject deny block fail no

There are two predefined filters, named ALWAYS and NEVER, which always
and never accept lines (respectively).

A context definition consists of a `context' line, then zero or more
`tell' and `listen' lines (which latter two may be intermixed
arbitrarily).

context NAME
	This begins the definition of a context.  NAME is a short name
	for it, used in the UI.

tell NAME THING
	These declare where user input to this context should go.  NAME
	is the name of a connection; THING is either a nick or a
	channel name.  Input is sent to that connection, addressed to
	that nick/channel.  Multiple tell lines for a context causes
	that context's input to go to multiple places.

listen FILTER WHAT
	WHAT is a trailing-text argument.

	FILTER is a filter name.  If the filter accepts the line, WHAT
	determines what happens.

	If WHAT's first character is a ", then the rest of it is
	processed to produce output displayed to the user.  When
	processing output text, most text is copied directly.
	Sequences of the form $(...) are replaced according to the text
	inside the ( ).  Note that $ is not special unless immediately
	followed by (.

		$(TYPE)
			The line's type, as for type= clauses in
			filters.

		$(PREFIX)
			The line's prefix, as for from= clauses in
			filters.

		$(CONN_NAME)
			The short name of the connection the line was
			received from.

		$(CONTENT)
			The content of the line.

		$(S/STRING/PATTERN/REPLACEMENT/NOMATCH/)
			Performs a regular-expression replacement.
			STRING, PATTERN, REPLACEMENT, and NOMATCH are
			processed for $(...) escapes; then, PATTERN is
			matched against STRING as a regular expression.
			If it matches, REPLACEMENT is processed for \n
			and \(n) escapes and the result is the
			expansion of the $(S...) form.  If it doesn't
			match, NOMATCH is the expansion.  / can be any
			non-alphanumeric character and serves to
			delimit STRING, PATTERN, REPLACEMENT, and
			NOMATCH.  There is no way to quote the
			delimiter into the arguments; however, once the
			arguments are isolated, the delimiter is no
			longer significant, and delimiter characters
			introduced by $(...) expansion within the
			arguments have no effect.

			Additionally, the arguments must be balanced
			with respect to $(...); delimiter characters
			within $(...) have no effect.  This allows
			$(S...) constructs to be nested without
			delimiter clashes.

		What results from other $(...) sequences is
		unspecified.

	Currently, " is the only kind of WHAT supported.  (The prefix
	character exists to allow for more general facilities to be
	added, such as taking automated actions in response to certain
	output.)

	If multiple listen lines are specified, they are processed in
	order, with each one being checked and possibly taking effect.

Startup configuration lines can be:

use context CTX

	Says that context CTX should be active at startup.  If no use
	context line is specified, or if one is but no context by that
	name is defined, an unspecified one of the defined contexts is
	active; if there are no contexts defined, there is no context
	active at startup.

	If multiple `use context' lines appear, all but the last one
	are ignored.