[Emacs-diffs] trunk r113910: Spelling fixes.

[Paul Eggert]

------------------------------------------------------------
revno: 113910
revision-id: address@hidden
parent: address@hidden
committer: Paul Eggert <address@hidden>
branch nick: trunk
timestamp: Thu 2013-08-15 22:15:51 -0700
message:
  Spelling fixes.
modified:
  doc/lispref/display.texi       
display.texi-20091113204419-o5vbwnq5f7feedwu-6172
  doc/misc/eieio.texi            
eieio.texi-20091113204419-o5vbwnq5f7feedwu-11397
  doc/misc/todo-mode.texi        todomode.texi-20130804212326-csuj921rpk9gy1gz-1
  etc/refcards/Makefile          makefile-20091113204419-o5vbwnq5f7feedwu-5192
  lisp/desktop.el                desktop.el-20091113204419-o5vbwnq5f7feedwu-591
  lisp/frameset.el               frameset.el-20130802043218-tfwraxv1c2zlibpw-1
  lisp/progmodes/python.el       python.el-20091113204419-o5vbwnq5f7feedwu-3008
  src/decompress.c               decompress.c-20130811194033-wfhl0tqmmc36jfmu-1
  src/image.c                    image.c-20091113204419-o5vbwnq5f7feedwu-2969
  src/process.c                  process.c-20091113204419-o5vbwnq5f7feedwu-462

=== modified file 'doc/lispref/display.texi'
--- a/doc/lispref/display.texi  2013-08-13 20:13:02 +0000
+++ b/doc/lispref/display.texi  2013-08-16 05:15:51 +0000
@@ -4667,7 +4667,7 @@
 @item :format
 ImageMagick tries to auto-detect the image type, but it isn't always
 able to.  By using @code{:format-type}, we can give ImageMagick a hint
-to try to help it.  It's used in conjuction with the
+to try to help it.  It's used in conjunction with the
 @code{image-format-suffixes} variable, which provides a mapping from
 content types to file name suffixes.  This is then given to
 ImageMagick as a file name hint.

=== modified file 'doc/misc/eieio.texi'
--- a/doc/misc/eieio.texi       2013-07-29 20:26:19 +0000
+++ b/doc/misc/eieio.texi       2013-08-16 05:15:51 +0000
@@ -256,7 +256,7 @@
 textbook or tutorial first, especially if you only know OOP from
 languages like C++ or Java.  If on the other hand you are already
 familiar with CLOS, you should be aware that @eieio{} does not implement
-the full CLOS specificiation and also differs in some other aspects
+the full CLOS specification and also differs in some other aspects
 (@xref{Introduction}, and @ref{CLOS compatibility}).
 
 A @dfn{class} is a definition for organizing data and methods

=== modified file 'doc/misc/todo-mode.texi'
--- a/doc/misc/todo-mode.texi   2013-08-07 14:15:23 +0000
+++ b/doc/misc/todo-mode.texi   2013-08-16 05:15:51 +0000
@@ -433,7 +433,7 @@
 
 @item F k
 Delete the current todo file (@code{todo-delete-file})address@hidden key
-binding of this command is mnenomic for ``kill'' to parallel the binding
+binding of this command is mnemonic for ``kill'' to parallel the binding
 @kbd{k} for item deletion, since @kbd{d} is bound to another item
 editing command (@pxref{Done Items}).}  If the todo file has an archive
 (@pxref{Todo Archive Mode}), prompt whether to delete that as well.
@@ -496,7 +496,7 @@
 
 @item C k
 Delete the current category (@code{todo-delete-category})address@hidden
-binding is mnenomic for ``kill'' to parallel the binding @kbd{k} for
+binding is mnemonic for ``kill'' to parallel the binding @kbd{k} for
 item deletion, since @kbd{d} is bound to another item editing command
 (@pxref{Done Items}).}  To delete a category that contains items, you
 have to confirm your intent; if the category is empty, deletion is
@@ -595,7 +595,7 @@
 text.  Each unique combination of these parameters produces a different
 insertion command.  The command @kbd{i i} realizes one of these
 combinations.  For the commands that realize the remaining combinations
-it is convenient to associate each parameter with a mnenomically chosen
+it is convenient to associate each parameter with a mnemonically chosen
 key.  Then by typing certain sequences of these keys, you complete the
 insertion command invocation that realizes the specified combination.
 As with @kbd{i i}, the effect of many of these commands also depends on
@@ -610,7 +610,7 @@
 @enumerate
 
 @item
address@hidden for diary (non)inclusion; 
address@hidden for diary (non)inclusion;
 @item
 @kbd{k} for adding or omitting `diary-nonmarking-symbol';
 @item
@@ -882,7 +882,7 @@
 
 @item k
 Delete the todo item at point (@code{todo-delete-item}; the binding is
-mnenomic for ``kill'', since @kbd{d} is used for marking items as done
+mnemonic for ``kill'', since @kbd{d} is used for marking items as done
 (@pxref{Done Items}); but note that @kbd{k} does not put the item into
 the kill ring).  This command requires confirmation that you want to
 delete the item, since you cannot undo the deletion in Todo mode.  (You
@@ -1170,7 +1170,7 @@
 
 You can mark both todo and done items, but note that only @kbd{m} can apply
 to both; other commands only affect either marked todo or marked done
-items, so if both types of items are marked, invoking these commmands
+items, so if both types of items are marked, invoking these commands
 has no effect and informs you of your erroneous attempt.
 
 @node Todo Categories Mode, Searching for Items, Marked Items, Top
@@ -1214,7 +1214,7 @@
 @node Table of Item Counts, Reordering Categories, , Todo Categories Mode
 @section Table of Item Counts
 
-Above each column of the table is a labelled button you can press by
+Above each column of the table is a labeled button you can press by
 clicking with the mouse or by typing @key{RET} on it.  Pressing an item
 count button sorts the table alternately in ascending or descending
 order according to the type of count.  Pressing the category button
@@ -1375,7 +1375,7 @@
 one for filtering a user-specified list of todo files.  Thus, there
 are six item filtering commands:@footnote{The use of @kbd{F} in the key
 sequences of these commands naturally recalls ``filter'', but is also
-consistent with the Todo mode mnenomic key binding convention, since the
+consistent with the Todo mode mnemonic key binding convention, since the
 commands involve one or more whole files.}
 
 @itemize @bullet
@@ -1533,7 +1533,7 @@
 @end table
 
 @itemize @bullet
address@hidden 
address@hidden
 As with tables of categories, by customizing @code{todo-show-first} you
 can have the first invocation of @code{todo-show} for a given todo file
 display the corresponding saved file of filtered items.  If there is
@@ -1548,7 +1548,7 @@
 @node Todo Display Features, Printing Todo Buffers, Todo Filtered Items Mode, 
Top
 @chapter Todo Display Features
 
-You can change the appearance of Todo mode buffers in a variety of ways.  
+You can change the appearance of Todo mode buffers in a variety of ways.
 
 @menu
 * Faces::
@@ -1567,7 +1567,7 @@
 @code{todo-nondiary-marker}) is earlier than the current date and time,
 they are displayed in a different face.  In this way, you can readily
 recognize diary items that have ``expired'' and act accordingly (e.g.,
-by tagging them as done or by updating the deadlines).  
+by tagging them as done or by updating the deadlines).
 
 Another example of an informational face is the face used to distinguish
 top priority items.  A third case is the face used in Todo Categories

=== modified file 'etc/refcards/Makefile'
--- a/etc/refcards/Makefile     2013-08-15 06:31:14 +0000
+++ b/etc/refcards/Makefile     2013-08-16 05:15:51 +0000
@@ -152,7 +152,7 @@
 ## A4, landscape: de-refcard, fr-refcard, pt-br-refcard orgcard
 ## A4, portrait: cs-*, fr-dired-ref, sk-*, pl-refcard, ru-refcard
 ## Letter, landscape: calccard, refcard
-## Letter, portrait (suffix rule): diref-ref, gnus-*, survival, vip*
+## Letter, portrait (suffix rule): dired-ref, gnus-*, survival, vip*
 
 calccard_deps = calccard.tex emacsver.tex pdflayout.sty
 calccard.pdf: $(calccard_deps)

=== modified file 'lisp/desktop.el'
--- a/lisp/desktop.el   2013-08-07 22:54:08 +0000
+++ b/lisp/desktop.el   2013-08-16 05:15:51 +0000
@@ -390,7 +390,7 @@
 
 (defcustom desktop-restore-forces-onscreen t
   "If t, offscreen frames are restored onscreen instead.
-If `:all', frames that are partially offscreen are also forced onscren.
+If `:all', frames that are partially offscreen are also forced onscreen.
 NOTE: Checking of frame boundaries is only approximate and can fail
 to reliably detect frames whose onscreen/offscreen state depends on a
 few pixels, especially near the right / bottom borders of the screen."
@@ -670,7 +670,7 @@
             ;; which already takes care of frame restoration and deletion.
             (called-interactively-p 'any))
     (let* ((this (selected-frame))
-          (mini (window-frame (minibuffer-window this)))) ; in case they difer
+          (mini (window-frame (minibuffer-window this)))) ; in case they differ
       (dolist (frame (sort (frame-list) #'frameset-minibufferless-first-p))
        (condition-case err
            (unless (or (eq frame this)
@@ -1032,7 +1032,7 @@
                      :force-onscreen desktop-restore-forces-onscreen)))
 
 ;; Just to silence the byte compiler.
-;; Dynamicaly bound in `desktop-read'.
+;; Dynamically bound in `desktop-read'.
 (defvar desktop-first-buffer)
 (defvar desktop-buffer-ok-count)
 (defvar desktop-buffer-fail-count)

=== modified file 'lisp/frameset.el'
--- a/lisp/frameset.el  2013-08-14 13:41:02 +0000
+++ b/lisp/frameset.el  2013-08-16 05:15:51 +0000
@@ -182,7 +182,7 @@
 ;; Let's say that Emacs' frame parameters were never designed as a tool to
 ;; precisely record (or restore) a frame's state.  They grew organically,
 ;; and their uses and behaviors reflect their history.  In using them to
-;; implement framesets, the unwary implementor, or the prospective package
+;; implement framesets, the unwary implementer, or the prospective package
 ;; writer willing to use framesets in their code, might fall victim of some
 ;; unexpected... oddities.
 ;;

=== modified file 'lisp/progmodes/python.el'
--- a/lisp/progmodes/python.el  2013-08-13 16:36:32 +0000
+++ b/lisp/progmodes/python.el  2013-08-16 05:15:51 +0000
@@ -3080,14 +3080,14 @@
             min-indent
             indent
             (if (<= indent children-indent-limit)
-                ;; This lays within the children indent offset range,
-                ;; so it's a normal children of its parent (i.e., not
-                ;; a children of a children).
+                ;; This lies within the children indent offset range,
+                ;; so it's a normal child of its parent (i.e., not
+                ;; a child of a child).
                 (cons (cons label pos) tree)
-              ;; Oh noes, a children of a children?!. Fear not, we
-              ;; know how to roll. We recursely parse these by
+              ;; Oh no, a child of a child?!  Fear not, we
+              ;; know how to roll.  We recursively parse these by
               ;; swapping prev-indent and min-indent plus adding this
-              ;; newly found item to a fresh subtree. This works, I
+              ;; newly found item to a fresh subtree.  This works, I
               ;; promise.
               (cons
                (python-imenu--build-tree

=== modified file 'src/decompress.c'
--- a/src/decompress.c  2013-08-14 12:47:05 +0000
+++ b/src/decompress.c  2013-08-16 05:15:51 +0000
@@ -164,7 +164,7 @@
   stream.avail_in = 0;
   stream.next_in = Z_NULL;
 
-  /* The magic number 32 apparently means "autodect both the gzip and
+  /* The magic number 32 apparently means "autodetect both the gzip and
      zlib formats" according to zlib.h.  */
   if (fn_inflateInit2 (&stream, MAX_WBITS + 32) != Z_OK)
     return Qnil;

=== modified file 'src/image.c'
--- a/src/image.c       2013-08-15 20:17:35 +0000
+++ b/src/image.c       2013-08-16 05:15:51 +0000
@@ -7934,7 +7934,7 @@
          return NULL;
        }
 
-      /* The sub-image may not start at origo, so move the destination
+      /* The sub-image may not start at origin, so move the destination
         iterator to where the sub-image should start. */
       if (source_top > 0)
        {

=== modified file 'src/process.c'
--- a/src/process.c     2013-08-15 14:52:53 +0000
+++ b/src/process.c     2013-08-16 05:15:51 +0000
@@ -1893,7 +1893,7 @@
 #ifndef WINDOWSNT
       /* Wait for child_setup to complete in case that vfork is
         actually defined as fork.  The descriptor
-        XPROCESS (proc)->open_fd[EXEC_MOINTOR_OUTPUT]
+        XPROCESS (proc)->open_fd[EXEC_MONITOR_OUTPUT]
         of a pipe is closed at the child side either by close-on-exec
         on successful execve or the _exit call in child_setup.  */
       {