menu-bar-select-buffer: Reinsert it as msb.el use it.

[gnu-emacs] / etc / DEBUG

diff --git a/etc/DEBUG b/etc/DEBUG
index 97e1f015a051f7bf488d3ea4c6449162857c1929..eaa8ca6f20d238c88a2d367d918ed0b954c8b562 100644 (file)
--- a/etc/DEBUG
+++ b/etc/DEBUG
@@ -1,11 +1,11 @@
 Debugging GNU Emacs
 
 Copyright (C) 1985, 2000, 2001, 2002, 2003, 2004,
-   2005, 2006, 2007 Free Software Foundation, Inc.
+   2005, 2006, 2007, 2008 Free Software Foundation, Inc.
 See the end of the file for license conditions.
 
 
-[People who debug Emacs on Windows using native Windows debuggers
+[People who debug Emacs on Windows using Microsoft debuggers
 should read the Windows-specific section near the end of this
 document.]
 
@@ -64,10 +64,10 @@ use the set command until the inferior process has been started.
 Put a breakpoint early in `main', or suspend the Emacs,
 to get an opportunity to do the set command.
 
-When Emacs is running in a terminal, it is useful to use a separate terminal
-for the debug session.  This can be done by starting Emacs as usual, then
-attaching to it from gdb with the `attach' command which is explained in the
-node "Attach" of the GDB manual.
+When Emacs is running in a terminal, it is sometimes useful to use a separate
+terminal for the debug session.  This can be done by starting Emacs as usual,
+then attaching to it from gdb with the `attach' command which is explained in
+the node "Attach" of the GDB manual.
 
 ** Examining Lisp object values.
 
@@ -567,7 +567,7 @@ are involved in the crash.
 
 Once you discover the corrupted Lisp object or data structure, grep
 the sources for its uses and try to figure out what could cause the
-corruption.  If looking at the sources doesn;t help, you could try
+corruption.  If looking at the sources doesn't help, you could try
 setting a watchpoint on the corrupted data, and see what code modifies
 it in some invalid way.  (Obviously, this technique is only useful for
 data that is modified only very rarely.)
@@ -731,7 +731,7 @@ prints the backtrace for a crash.  It is usually best to look at the
 disassembly to determine exactly what code is being run--the
 disassembly will probably show several source lines followed by a
 block of assembler for those lines.  The actual point where Emacs
-crashes will be one of those source lines, but not neccesarily the one
+crashes will be one of those source lines, but not necessarily the one
 that the debugger reports.
 
 Another problematic area with the MS debugger is with variables that
@@ -746,10 +746,10 @@ of these variables.
 \f
 This file is part of GNU Emacs.
 
-GNU Emacs is free software; you can redistribute it and/or modify
+GNU Emacs is free software: you can redistribute it and/or modify
 it under the terms of the GNU General Public License as published by
-the Free Software Foundation; either version 2, or (at your option)
-any later version.
+the Free Software Foundation, either version 3 of the License, or
+(at your option) any later version.
 
 GNU Emacs is distributed in the hope that it will be useful,
 but WITHOUT ANY WARRANTY; without even the implied warranty of
@@ -757,9 +757,7 @@ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 GNU General Public License for more details.
 
 You should have received a copy of the GNU General Public License
-along with GNU Emacs; see the file COPYING.  If not, write to the
-Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor,
-Boston, MA 02110-1301, USA.
+along with GNU Emacs.  If not, see <http://www.gnu.org/licenses/>.
 
 \f
 Local variables: