+@menu
+* Controlling Verbosity::
+* Diagnostic Severity::
+* Understanding Compiler Diagnostics::
+@end menu
+
+@node Controlling Verbosity
+@comment node-name, next, previous, up
+@subsection Controlling Verbosity
+
+The compiler can be quite verbose in its diagnostic reporting, rather
+more then some users would prefer -- the amount of noise emitted can
+be controlled, however.
+
+To control emission of compiler diagnostics (of any severity other
+than @code{error}: @pxref{Diagnostic Severity}) use the
+@code{sb-ext:muffle-conditions} and @code{sb-ext:unmuffle-conditions}
+declarations, specifying the type of condition that is to be muffled
+(the muffling is done using an associated @code{muffle-warning} restart).
+
+Global control:
+@lisp
+;;; Muffle compiler-notes globally
+(declaim (sb-ext:muffle-conditions sb-ext:compiler-note))
+@end lisp
+
+Local control:
+@lisp
+;;; Muffle compiler-notes based on lexical scope
+(defun foo (x)
+ (declare (optimize speed) (fixnum x)
+ (sb-ext:muffle-conditions sb-ext:compiler-note))
+ (values (* x 5) ; no compiler note from this
+ (locally
+ (declare (sb-ext:unmuffle-conditions sb-ext:compiler-note))
+ ;; this one gives a compiler note
+ (* x -5))))
+@end lisp
+
+@deffn {Declaration} sb-ext:muffle-conditions
+Syntax: type*
+
+Muffles the diagnostic messages that would be caused by compile-time
+signals of given types.
+@end deffn
+
+@deffn {Declaration} sb-ext:unmuffle-conditions
+Syntax: type*
+
+Cancels the effect of a previous @code{sb-ext:muffle-condition}
+declaration.
+@end deffn
+
+Various details of @emph{how} the compiler messages are printed can be
+controlled via the alist
+@code{sb-ext:*compiler-print-variable-alist*}.
+
+@include var-sb-ext-star-compiler-print-variable-alist-star.texinfo
+
+@c <!-- FIXME: How much control over error messages is in SBCL?
+@c _ How much should be? How much of this documentation should
+@c _ we save or adapt?
+@c _
+@c _ %%\node Error Message Parameterization, , Read Errors, Interpreting Error Messages
+@c _ \subsection{Error Message Parameterization}
+@c _ \cpsubindex{error messages}{verbosity}
+@c _ \cpsubindex{verbosity}{of error messages}
+@c _
+@c _ There is some control over the verbosity of error messages. See also
+@c _ \varref{undefined-warning-limit}, \code{*efficiency-note-limit*} and
+@c _ \varref{efficiency-note-cost-threshold}.
+@c _
+@c _ \begin{defvar}{}{enclosing-source-cutoff}
+@c _
+@c _ This variable specifies the number of enclosing actual source forms
+@c _ that are printed in full, rather than in the abbreviated processing
+@c _ path format. Increasing the value from its default of \code{1}
+@c _ allows you to see more of the guts of the macroexpanded source,
+@c _ which is useful when debugging macros.
+@c _ \end{defvar}
+@c _
+@c _ \begin{defmac}{extensions:}{define-source-context}{%
+@c _ \args{\var{name} \var{lambda-list} \mstar{form}}}
+@c _
+@c _ This macro defines how to extract an abbreviated source context from
+@c _ the \var{name}d form when it appears in the compiler input.
+@c _ \var{lambda-list} is a \code{defmacro} style lambda-list used to
+@c _ parse the arguments. The \var{body} should return a list of
+@c _ subforms that can be printed on about one line. There are
+@c _ predefined methods for \code{defstruct}, \code{defmethod}, etc. If
+@c _ no method is defined, then the first two subforms are returned.
+@c _ Note that this facility implicitly determines the string name
+@c _ associated with anonymous functions.
+@c _ \end{defmac}
+@c _
+@c _ -->
+
+@node Diagnostic Severity
+@comment node-name, next, previous, up
+@subsection Diagnostic Severity
+@cindex Severity of compiler messages
+@cindex Compiler Diagnostic Severity
+@tindex error
+@tindex warning
+@tindex style-warning
+@tindex compiler-note
+@tindex code-deletion-note
+
+There are four levels of compiler diagnostic severity:
+
+@enumerate 1
+@item error
+@item warning
+@item style warning
+@item note
+@end enumerate
+
+The first three levels correspond to condition classes which are
+defined in the ANSI standard for Common Lisp and which have special
+significance to the @code{compile} and @code{compile-file} functions.
+These levels of compiler error severity occur when the compiler
+handles conditions of these classes.
+
+The fourth level of compiler error severity, @emph{note}, corresponds
+to the @code{sb-ext:compiler-note}, and is used for problems which are
+too mild for the standard condition classes, typically hints about how
+efficiency might be improved. The @code{sb-ext:code-deletion-note}, a
+subtype of @code{compiler-note}, is signalled when the compiler
+deletes user-supplied code, usually after proving that the code in
+question is unreachable.
+
+Future work for SBCL includes expanding this hierarchy of types to
+allow more fine-grained control over emission of diagnostic messages.
+
+@include condition-sb-ext-compiler-note.texinfo
+@include condition-sb-ext-code-deletion-note.texinfo
+
+
+@node Understanding Compiler Diagnostics
+@comment node-name, next, previous, up
+@subsection Understanding Compile Diagnostics
+
+The messages emitted by the compiler contain a lot of detail in a
+terse format, so they may be confusing at first. The messages will be