4 files changed, 64 insertions, 18 deletions

diff --git a/lispref/ChangeLog b/lispref/ChangeLog
index 5c25f0945a9..5102e723566 100644
--- a/lispref/ChangeLog
+++ b/lispref/ChangeLog
@@ -1,6 +1,23 @@
+2007-07-14  Richard Stallman  <rms@gnu.org>
+
+        * control.texi (Handling Errors): Document `debug' in handler list.
+
+2007-07-10  Richard Stallman  <rms@gnu.org>
+
+        * display.texi (Defining Faces): Explain C-M-x feature for defface.
+
+2007-07-09  Richard Stallman  <rms@gnu.org>
+
+        * files.texi (Magic File Names): Rewrite previous change.
+
+2007-07-08  Michael Albinus  <michael.albinus@gmx.de>
+
+        * files.texi (Magic File Names): Introduce optional parameter
+        CONNECTED for `file-remote-p'.
+
 2007-07-07  Michael Albinus  <michael.albinus@gmx.de>
 
-        * process.texi (Asynchronous Processes):
+        * processes.texi (Asynchronous Processes):
         * files.texi (Magic File Names): Add `start-file-process'.
 
 2007-06-27  Richard Stallman  <rms@gnu.org>
diff --git a/lispref/control.texi b/lispref/control.texi
index 4c469a10368..e99a6329f3e 100644
--- a/lispref/control.texi
+++ b/lispref/control.texi
@@ -893,6 +893,12 @@ establishing an error handler, with the special form
 This deletes the file named @var{filename}, catching any error and
 returning @code{nil} if an error occurs.
 
+  The @code{condition-case} construct is often used to trap errors that
+are predictable, such as failure to open a file in a call to
+@code{insert-file-contents}.  It is also used to trap errors that are
+totally unpredictable, such as when the program evaluates an expression
+read from the user.
+
   The second argument of @code{condition-case} is called the
 @dfn{protected form}.  (In the example above, the protected form is a
 call to @code{delete-file}.)  The error handlers go into effect when
@@ -920,15 +926,33 @@ the two gets to handle it.
   If an error is handled by some @code{condition-case} form, this
 ordinarily prevents the debugger from being run, even if
 @code{debug-on-error} says this error should invoke the debugger.
-@xref{Error Debugging}.  If you want to be able to debug errors that are
-caught by a @code{condition-case}, set the variable
-@code{debug-on-signal} to a non-@code{nil} value.
 
-  When an error is handled, control returns to the handler.  Before this
-happens, Emacs unbinds all variable bindings made by binding constructs
-that are being exited and executes the cleanups of all
-@code{unwind-protect} forms that are exited.  Once control arrives at
-the handler, the body of the handler is executed.
+  If you want to be able to debug errors that are caught by a
+@code{condition-case}, set the variable @code{debug-on-signal} to a
+non-@code{nil} value.  You can also specify that a particular handler
+should let the debugger run first, by writing @code{debug} among the
+conditions, like this:
+
+@example
+@group
+(condition-case nil
+    (delete-file filename)
+  ((debug error) nil))
+@end group
+@end example
+
+@noindent
+The effect of @code{debug} here is only to prevent
+@code{condition-case} from suppressing the call to the debugger.  Any
+given error will invoke the debugger only if @code{debug-on-error} and
+the other usual filtering mechanisms say it should.  @xref{Error Debugging}.
+
+  Once Emacs decides that a certain handler handles the error, it
+returns control to that handler.  To do so, Emacs unbinds all variable
+bindings made by binding constructs that are being exited, and
+executes the cleanups of all @code{unwind-protect} forms that are
+being exited.  Once control arrives at the handler, the body of the
+handler executes normally.
 
   After execution of the handler body, execution returns from the
 @code{condition-case} form.  Because the protected form is exited
@@ -937,12 +961,6 @@ execution at the point of the error, nor can it examine variable
 bindings that were made within the protected form.  All it can do is
 clean up and proceed.
 
-  The @code{condition-case} construct is often used to trap errors that
-are predictable, such as failure to open a file in a call to
-@code{insert-file-contents}.  It is also used to trap errors that are
-totally unpredictable, such as when the program evaluates an expression
-read from the user.
-
   Error signaling and handling have some resemblance to @code{throw} and
 @code{catch} (@pxref{Catch and Throw}), but they are entirely separate
 facilities.  An error cannot be caught by a @code{catch}, and a
@@ -960,7 +978,8 @@ error occurs during @var{protected-form}.
 
 Each of the @var{handlers} is a list of the form @code{(@var{conditions}
 @var{body}@dots{})}.  Here @var{conditions} is an error condition name
-to be handled, or a list of condition names; @var{body} is one or more
+to be handled, or a list of condition names (which can include @code{debug}
+to allow the debugger to run before the handler); @var{body} is one or more
 Lisp expressions to be executed when this handler handles an error.
 Here are examples of handlers:
 
diff --git a/lispref/display.texi b/lispref/display.texi
index 664ad1d2c15..f4d7a5dbcdb 100644
--- a/lispref/display.texi
+++ b/lispref/display.texi
@@ -1760,6 +1760,11 @@ When @code{defface} executes, it defines the face according to
 @var{spec}, then uses any customizations that were read from the
 init file (@pxref{Init File}) to override that specification.
 
+When you evaluate a @code{defcustom} form with @kbd{C-M-x} in Emacs
+Lisp mode (@code{eval-defun}), a special feature of @code{eval-defun}
+overrides any customizations of the face.  This way, the face reflects
+exactly what the @code{defcustom} says.
+
 The purpose of @var{spec} is to specify how the face should appear on
 different kinds of terminals.  It should be an alist whose elements
 have the form @code{(@var{display} @var{atts})}.  Each element's
diff --git a/lispref/files.texi b/lispref/files.texi
index 5af77fafc31..343a6bc5e39 100644
--- a/lispref/files.texi
+++ b/lispref/files.texi
@@ -2768,7 +2768,7 @@ nothing and returns @code{nil}.  Otherwise it returns the file name
 of the local copy file.
 @end defun
 
-@defun file-remote-p filename
+@defun file-remote-p filename &optional connected
 This function tests whether @var{filename} is a remote file.  If
 @var{filename} is local (not remote), the return value is @code{nil}.
 If @var{filename} is indeed remote, the return value is a string that
@@ -2777,7 +2777,7 @@ identifies the remote system.
 This identifier string can include a host name and a user name, as
 well as characters designating the method used to access the remote
 system.  For example, the remote identifier string for the filename
-@code{/ssh:user@@host:/some/file} is @code{/ssh:user@@host:}.
+@code{/sudo::/some/file} is @code{/sudo:root@@localhost:}.
 
 If @code{file-remote-p} returns the same identifier for two different
 filenames, that means they are stored on the same file system and can
@@ -2785,6 +2785,11 @@ be accessed locally with respect to each other.  This means, for
 example, that it is possible to start a remote process accessing both
 files at the same time.  Implementors of file handlers need to ensure
 this principle is valid.
+
+If @var{connected} is non-@code{nil}, this function returns @code{nil}
+even if @var{filename} is remote, if Emacs has no network connection
+to its host.  This is useful when you want to avoid the delay of
+making connections when they don't exist.
 @end defun
 
 @defun unhandled-file-name-directory filename