mirror of
https://git.savannah.gnu.org/git/emacs.git
synced 2024-11-24 07:20:37 +00:00
Put period and comma inside quotes.
This commit is contained in:
parent
13cad73874
commit
827b7ee7c2
@ -97,7 +97,7 @@ in a while, to keep Emacs Lisp programmers on their toes.
|
||||
@item
|
||||
The @code{min-colors} face attribute, used for tailoring faces to
|
||||
limited-color displays, does not exist. If in doubt, use colors like
|
||||
``white'' and ``black'', which ought to be defined everywhere.
|
||||
``white'' and ``black,'' which ought to be defined everywhere.
|
||||
|
||||
@item
|
||||
The @code{tty-color-mode} frame parameter does not exist. You should
|
||||
@ -170,7 +170,7 @@ the sentinel.
|
||||
|
||||
@item
|
||||
Many programming shortcuts have been deleted, to provide you with the
|
||||
enjoyment of ``rolling your own''. The macros @code{while-no-input},
|
||||
enjoyment of ``rolling your own.'' The macros @code{while-no-input},
|
||||
@code{with-local-quit}, and @code{with-selected-window}, along with
|
||||
@code{dynamic-completion-table} and @code{lazy-completion-table} no
|
||||
longer exist. Also, there are no built-in progress reporters;
|
||||
|
@ -484,7 +484,7 @@ correspond to the new file name, unless the new name is already in
|
||||
use.
|
||||
|
||||
If @var{filename} is @code{nil} or the empty string, that stands for
|
||||
``no visited file''. In this case, @code{set-visited-file-name} marks
|
||||
``no visited file.'' In this case, @code{set-visited-file-name} marks
|
||||
the buffer as having no visited file, without changing the buffer's
|
||||
modified flag.
|
||||
|
||||
|
@ -2165,7 +2165,7 @@ same symbol that would normally represent that combination of mouse
|
||||
button and modifier keys. The information about the window part is kept
|
||||
elsewhere in the event---in the coordinates. But
|
||||
@code{read-key-sequence} translates this information into imaginary
|
||||
``prefix keys'', all of which are symbols: @code{header-line},
|
||||
``prefix keys,'' all of which are symbols: @code{header-line},
|
||||
@code{horizontal-scroll-bar}, @code{menu-bar}, @code{mode-line},
|
||||
@code{vertical-line}, and @code{vertical-scroll-bar}. You can define
|
||||
meanings for mouse clicks in special window parts by defining key
|
||||
@ -2410,7 +2410,7 @@ individual events, which you can put in @code{unread-command-events}.
|
||||
|
||||
@defvar unread-command-char
|
||||
This variable holds a character to be read as command input.
|
||||
A value of -1 means ``empty''.
|
||||
A value of -1 means ``empty.''
|
||||
|
||||
This variable is mostly obsolete now that you can use
|
||||
@code{unread-command-events} instead; it exists only to support programs
|
||||
@ -2898,7 +2898,7 @@ using the minibuffer. Usually it is more convenient for the user if you
|
||||
change the major mode of the current buffer temporarily to a special
|
||||
major mode, which should have a command to go back to the previous mode.
|
||||
(The @kbd{e} command in Rmail uses this technique.) Or, if you wish to
|
||||
give the user different text to edit ``recursively'', create and select
|
||||
give the user different text to edit ``recursively,'' create and select
|
||||
a new buffer in a special mode. In this mode, define a command to
|
||||
complete the processing and go back to the previous buffer. (The
|
||||
@kbd{m} command in Rmail does this.)
|
||||
|
@ -221,7 +221,7 @@ non-@code{nil}, the clause ``succeeds''; then @code{cond} evaluates its
|
||||
@var{body-forms}, and the value of the last of @var{body-forms} becomes
|
||||
the value of the @code{cond}. The remaining clauses are ignored.
|
||||
|
||||
If the value of @var{condition} is @code{nil}, the clause ``fails'', so
|
||||
If the value of @var{condition} is @code{nil}, the clause ``fails,'' so
|
||||
the @code{cond} moves on to the following clause, trying its
|
||||
@var{condition}.
|
||||
|
||||
@ -623,7 +623,7 @@ error is signaled with data @code{(@var{tag} @var{value})}.
|
||||
@subsection Examples of @code{catch} and @code{throw}
|
||||
|
||||
One way to use @code{catch} and @code{throw} is to exit from a doubly
|
||||
nested loop. (In most languages, this would be done with a ``go to''.)
|
||||
nested loop. (In most languages, this would be done with a ``go to.'')
|
||||
Here we compute @code{(foo @var{i} @var{j})} for @var{i} and @var{j}
|
||||
varying from 0 to 9:
|
||||
|
||||
|
@ -141,7 +141,7 @@ boundary. @xref{Filling}.
|
||||
indicate truncated and continued lines (@pxref{Fringes}). On a text
|
||||
terminal, a @samp{$} in the rightmost column of the window indicates
|
||||
truncation; a @samp{\} on the rightmost column indicates a line that
|
||||
``wraps''. (The display table can specify alternate characters to use
|
||||
``wraps.'' (The display table can specify alternate characters to use
|
||||
for this; @pxref{Display Tables}).
|
||||
|
||||
@defopt truncate-lines
|
||||
@ -1189,7 +1189,7 @@ The return value is @var{overlay}.
|
||||
This is the only valid way to change the endpoints of an overlay. Do
|
||||
not try modifying the markers in the overlay by hand, as that fails to
|
||||
update other vital data structures and can cause some overlays to be
|
||||
``lost''.
|
||||
``lost.''
|
||||
@end defun
|
||||
|
||||
@defun remove-overlays &optional start end name value
|
||||
@ -2013,7 +2013,7 @@ A non-@code{nil} value specifies a bold font.
|
||||
A non-@code{nil} value specifies an italic font.
|
||||
@end table
|
||||
|
||||
For compatibility, you can still set these ``attributes'', even
|
||||
For compatibility, you can still set these ``attributes,'' even
|
||||
though they are not real face attributes. Here is what that does:
|
||||
|
||||
@table @code
|
||||
@ -3767,7 +3767,7 @@ $$\pmatrix{ 2 & -1 & 0 \cr
|
||||
@end ifnottex
|
||||
|
||||
@item disabled
|
||||
Specifies transforming the image so that it looks ``disabled''.
|
||||
Specifies transforming the image so that it looks ``disabled.''
|
||||
@end table
|
||||
|
||||
@item :mask @var{mask}
|
||||
@ -4804,7 +4804,7 @@ Any @var{args} are passed to @var{map-function}.
|
||||
@subsection Abstract Display Example
|
||||
|
||||
Here is a simple example using functions of the ewoc package to
|
||||
implement a ``color components display'', an area in a buffer that
|
||||
implement a ``color components display,'' an area in a buffer that
|
||||
represents a vector of three integers (itself representing a 24-bit RGB
|
||||
value) in various ways.
|
||||
|
||||
@ -5320,7 +5320,7 @@ variable.
|
||||
@section Window Systems
|
||||
|
||||
Emacs works with several window systems, most notably the X Window
|
||||
System. Both Emacs and X use the term ``window'', but use it
|
||||
System. Both Emacs and X use the term ``window,'' but use it
|
||||
differently. An Emacs frame is a single window as far as X is
|
||||
concerned; the individual Emacs windows are not known to X at all.
|
||||
|
||||
|
@ -24,7 +24,7 @@ Secondarily, this License preserves for the author and publisher a way
|
||||
to get credit for their work, while not being considered responsible
|
||||
for modifications made by others.
|
||||
|
||||
This License is a kind of ``copyleft'', which means that derivative
|
||||
This License is a kind of ``copyleft,'' which means that derivative
|
||||
works of the document must themselves be free in the same sense. It
|
||||
complements the GNU General Public License, which is a copyleft
|
||||
license designed for free software.
|
||||
@ -45,9 +45,9 @@ This License applies to any manual or other work, in any medium, that
|
||||
contains a notice placed by the copyright holder saying it can be
|
||||
distributed under the terms of this License. Such a notice grants a
|
||||
world-wide, royalty-free license, unlimited in duration, to use that
|
||||
work under the conditions stated herein. The ``Document'', below,
|
||||
work under the conditions stated herein. The ``Document,'' below,
|
||||
refers to any such manual or work. Any member of the public is a
|
||||
licensee, and is addressed as ``you''. You accept the license if you
|
||||
licensee, and is addressed as ``you.'' You accept the license if you
|
||||
copy, modify or distribute the work in a way requiring permission
|
||||
under copyright law.
|
||||
|
||||
@ -114,8 +114,8 @@ preceding the beginning of the body of the text.
|
||||
A section ``Entitled XYZ'' means a named subunit of the Document whose
|
||||
title either is precisely XYZ or contains XYZ in parentheses following
|
||||
text that translates XYZ in another language. (Here XYZ stands for a
|
||||
specific section name mentioned below, such as ``Acknowledgements'',
|
||||
``Dedications'', ``Endorsements'', or ``History''.) To ``Preserve the Title''
|
||||
specific section name mentioned below, such as ``Acknowledgements,''
|
||||
``Dedications,'' ``Endorsements,'' or ``History.'') To ``Preserve the Title''
|
||||
of such a section when you modify the Document means that it remains a
|
||||
section ``Entitled XYZ'' according to this definition.
|
||||
|
||||
@ -211,7 +211,7 @@ F. Include, immediately after the copyright notices, a license notice
|
||||
G. Preserve in that license notice the full lists of Invariant Sections
|
||||
and required Cover Texts given in the Document's license notice.@*
|
||||
H. Include an unaltered copy of this License.@*
|
||||
I. Preserve the section Entitled ``History'', Preserve its Title, and add
|
||||
I. Preserve the section Entitled ``History,'' Preserve its Title, and add
|
||||
to it an item stating at least the title, year, new authors, and
|
||||
publisher of the Modified Version as given on the Title Page. If
|
||||
there is no section Entitled ``History'' in the Document, create one
|
||||
@ -225,7 +225,7 @@ J. Preserve the network location, if any, given in the Document for
|
||||
You may omit a network location for a work that was published at
|
||||
least four years before the Document itself, or if the original
|
||||
publisher of the version it refers to gives permission.@*
|
||||
K. For any section Entitled ``Acknowledgements'' or ``Dedications'',
|
||||
K. For any section Entitled ``Acknowledgements'' or ``Dedications,''
|
||||
Preserve the Title of the section, and preserve in the section all
|
||||
the substance and tone of each of the contributor acknowledgements
|
||||
and/or dedications given therein.@*
|
||||
@ -245,7 +245,7 @@ of these sections as invariant. To do this, add their titles to the
|
||||
list of Invariant Sections in the Modified Version's license notice.
|
||||
These titles must be distinct from any other section titles.
|
||||
|
||||
You may add a section Entitled ``Endorsements'', provided it contains
|
||||
You may add a section Entitled ``Endorsements,'' provided it contains
|
||||
nothing but endorsements of your Modified Version by various
|
||||
parties--for example, statements of peer review or that the text has
|
||||
been approved by an organization as the authoritative definition of a
|
||||
@ -286,7 +286,7 @@ Invariant Sections in the license notice of the combined work.
|
||||
|
||||
In the combination, you must combine any sections Entitled ``History''
|
||||
in the various original documents, forming one section Entitled
|
||||
``History''; likewise combine any sections Entitled ``Acknowledgements'',
|
||||
``History''; likewise combine any sections Entitled ``Acknowledgements,''
|
||||
and any sections Entitled ``Dedications.'' You must delete all sections
|
||||
Entitled ``Endorsements.''
|
||||
@sp 1
|
||||
@ -340,8 +340,8 @@ of those notices and disclaimers. In case of a disagreement between
|
||||
the translation and the original version of this License or a notice
|
||||
or disclaimer, the original version will prevail.
|
||||
|
||||
If a section in the Document is Entitled ``Acknowledgements'',
|
||||
``Dedications'', or ``History'', the requirement (section 4) to Preserve
|
||||
If a section in the Document is Entitled ``Acknowledgements,''
|
||||
``Dedications,'' or ``History,'' the requirement (section 4) to Preserve
|
||||
its Title (section 1) will typically require changing the actual
|
||||
title.
|
||||
@sp 1
|
||||
@ -390,7 +390,7 @@ under the terms of the GNU Free Documentation License, Version 1.2
|
||||
or any later version published by the Free Software Foundation;
|
||||
with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.
|
||||
A copy of the license is included in the section entitled ``GNU
|
||||
Free Documentation License''.
|
||||
Free Documentation License.''
|
||||
@end group
|
||||
@end smallexample
|
||||
|
||||
|
@ -658,7 +658,7 @@ The file lock is really a file, a symbolic link with a special name,
|
||||
stored in the same directory as the file you are editing.
|
||||
|
||||
When you access files using NFS, there may be a small probability that
|
||||
you and another user will both lock the same file ``simultaneously''.
|
||||
you and another user will both lock the same file ``simultaneously.''
|
||||
If this happens, it is possible for the two users to make changes
|
||||
simultaneously, but Emacs will still warn the user who saves second.
|
||||
Also, the detection of modification of a buffer visiting a file changed
|
||||
@ -1681,7 +1681,7 @@ return value, but backup version numbers are kept.
|
||||
@end defun
|
||||
|
||||
@defun file-name-extension filename &optional period
|
||||
This function returns @var{filename}'s final ``extension'', if any,
|
||||
This function returns @var{filename}'s final ``extension,'' if any,
|
||||
after applying @code{file-name-sans-versions} to remove any
|
||||
version/backup part. The extension, in a file name, is the part that
|
||||
starts with the last @samp{.} in the last name component (minus
|
||||
@ -2653,7 +2653,7 @@ unlocking the buffer if it is locked.
|
||||
possibly others to be added in the future. It need not implement all
|
||||
these operations itself---when it has nothing special to do for a
|
||||
certain operation, it can reinvoke the primitive, to handle the
|
||||
operation ``in the usual way''. It should always reinvoke the primitive
|
||||
operation ``in the usual way.'' It should always reinvoke the primitive
|
||||
for an operation it does not recognize. Here's one way to do this:
|
||||
|
||||
@smallexample
|
||||
|
@ -641,7 +641,7 @@ This variable specifies how to blink the cursor. Each element has the
|
||||
form @code{(@var{on-state} . @var{off-state})}. Whenever the cursor
|
||||
type equals @var{on-state} (comparing using @code{equal}), the
|
||||
corresponding @var{off-state} specifies what the cursor looks like
|
||||
when it blinks ``off''. Both @var{on-state} and @var{off-state}
|
||||
when it blinks ``off.'' Both @var{on-state} and @var{off-state}
|
||||
should be suitable values for the @code{cursor-type} frame parameter.
|
||||
|
||||
There are various defaults for how to blink each type of cursor, if
|
||||
@ -967,7 +967,7 @@ internals of Emacs.
|
||||
@defun visible-frame-list
|
||||
This function returns a list of just the currently visible frames.
|
||||
@xref{Visibility of Frames}. (Terminal frames always count as
|
||||
``visible'', even though only the selected one is actually displayed.)
|
||||
``visible,'' even though only the selected one is actually displayed.)
|
||||
@end defun
|
||||
|
||||
@defun next-frame &optional frame minibuf
|
||||
@ -1251,7 +1251,7 @@ changes. @xref{Misc Events}.
|
||||
Most window systems use a desktop metaphor. Part of this metaphor is
|
||||
the idea that windows are stacked in a notional third dimension
|
||||
perpendicular to the screen surface, and thus ordered from ``highest''
|
||||
to ``lowest''. Where two windows overlap, the one higher up covers
|
||||
to ``lowest.'' Where two windows overlap, the one higher up covers
|
||||
the one underneath. Even a window at the bottom of the stack can be
|
||||
seen if no other window overlaps it.
|
||||
|
||||
@ -1259,7 +1259,7 @@ seen if no other window overlaps it.
|
||||
@cindex lowering a frame
|
||||
A window's place in this ordering is not fixed; in fact, users tend
|
||||
to change the order frequently. @dfn{Raising} a window means moving
|
||||
it ``up'', to the top of the stack. @dfn{Lowering} a window means
|
||||
it ``up,'' to the top of the stack. @dfn{Lowering} a window means
|
||||
moving it to the bottom of the stack. This motion is in the notional
|
||||
third dimension only, and does not change the position of the window
|
||||
on the screen.
|
||||
@ -1519,7 +1519,7 @@ the menu keymap as necessary.
|
||||
A dialog box is a variant of a pop-up menu---it looks a little
|
||||
different, it always appears in the center of a frame, and it has just
|
||||
one level and one or more buttons. The main use of dialog boxes is
|
||||
for asking questions that the user can answer with ``yes'', ``no'',
|
||||
for asking questions that the user can answer with ``yes,'' ``no,''
|
||||
and a few other alternatives. With a single button, they can also
|
||||
force the user to acknowledge important information. The functions
|
||||
@code{y-or-n-p} and @code{yes-or-no-p} use dialog boxes instead of the
|
||||
@ -1780,7 +1780,7 @@ colors.)
|
||||
These functions provide a way to determine which color names are
|
||||
valid, and what they look like. In some cases, the value depends on the
|
||||
@dfn{selected frame}, as described below; see @ref{Input Focus}, for the
|
||||
meaning of the term ``selected frame''.
|
||||
meaning of the term ``selected frame.''
|
||||
|
||||
@defun color-defined-p color &optional frame
|
||||
This function reports whether a color name is meaningful. It returns
|
||||
@ -2150,7 +2150,7 @@ software (as a string). Really this means whoever distributes the X
|
||||
server.
|
||||
|
||||
When the developers of X labelled software distributors as
|
||||
``vendors'', they showed their false assumption that no system could
|
||||
``vendors,'' they showed their false assumption that no system could
|
||||
ever be developed and distributed noncommercially.
|
||||
@end defun
|
||||
|
||||
|
@ -485,7 +485,7 @@ more convenient than making the function definition point to itself
|
||||
practice).
|
||||
|
||||
We often identify functions with the symbols used to name them. For
|
||||
example, we often speak of ``the function @code{car}'', not
|
||||
example, we often speak of ``the function @code{car},'' not
|
||||
distinguishing between the symbol @code{car} and the primitive
|
||||
subr-object that is its function definition. For most purposes, the
|
||||
distinction is not important.
|
||||
@ -846,7 +846,7 @@ bool-vector, or a string.
|
||||
|
||||
In Lisp, a function is a list that starts with @code{lambda}, a
|
||||
byte-code function compiled from such a list, or alternatively a
|
||||
primitive subr-object; names are ``extra''. Although usually functions
|
||||
primitive subr-object; names are ``extra.'' Although usually functions
|
||||
are defined with @code{defun} and given names at the same time, it is
|
||||
occasionally more concise to use an explicit lambda expression---an
|
||||
anonymous function. Such a list is valid wherever a function name is.
|
||||
|
@ -75,13 +75,13 @@ modification follow.
|
||||
@item
|
||||
This License applies to any program or other work which contains
|
||||
a notice placed by the copyright holder saying it may be distributed
|
||||
under the terms of this General Public License. The ``Program'', below,
|
||||
under the terms of this General Public License. The ``Program,'' below,
|
||||
refers to any such program or work, and a ``work based on the Program''
|
||||
means either the Program or any derivative work under copyright law:
|
||||
that is to say, a work containing the Program or a portion of it,
|
||||
either verbatim or with modifications and/or translated into another
|
||||
language. (Hereinafter, translation is included without limitation in
|
||||
the term ``modification''.) Each licensee is addressed as ``you''.
|
||||
the term ``modification.'') Each licensee is addressed as ``you.''
|
||||
|
||||
Activities other than copying, distribution and modification are not
|
||||
covered by this License; they are outside its scope. The act of
|
||||
@ -274,7 +274,7 @@ address new problems or concerns.
|
||||
|
||||
Each version is given a distinguishing version number. If the Program
|
||||
specifies a version number of this License which applies to it and ``any
|
||||
later version'', you have the option of following the terms and conditions
|
||||
later version,'' you have the option of following the terms and conditions
|
||||
either of that version or of any later version published by the Free
|
||||
Software Foundation. If the Program does not specify a version number of
|
||||
this License, you may choose any version ever published by the Free Software
|
||||
|
@ -79,13 +79,13 @@ alternatives:
|
||||
Keys which are numbers are ``the same'' if they are @code{equal}, that
|
||||
is, if they are equal in value and either both are integers or both
|
||||
are floating point numbers; otherwise, two distinct objects are never
|
||||
``the same''.
|
||||
``the same.''
|
||||
|
||||
@item eq
|
||||
Any two distinct Lisp objects are ``different'' as keys.
|
||||
|
||||
@item equal
|
||||
Two Lisp objects are ``the same'', as keys, if they are equal
|
||||
Two Lisp objects are ``the same,'' as keys, if they are equal
|
||||
according to @code{equal}.
|
||||
@end table
|
||||
|
||||
|
@ -1270,7 +1270,7 @@ Non-@code{nil} means current value of @code{start} was the beginning of a line
|
||||
when it was chosen.
|
||||
|
||||
@item too_small_ok
|
||||
Non-@code{nil} means don't delete this window for becoming ``too small''.
|
||||
Non-@code{nil} means don't delete this window for becoming ``too small.''
|
||||
|
||||
@item height_fixed_p
|
||||
This field is temporarily set to 1 to fix the height of the selected
|
||||
|
@ -160,7 +160,7 @@ printer'' refer to those routines in Lisp that convert textual
|
||||
representations of Lisp objects into actual Lisp objects, and vice
|
||||
versa. @xref{Printed Representation}, for more details. You, the
|
||||
person reading this manual, are thought of as ``the programmer'' and are
|
||||
addressed as ``you''. ``The user'' is the person who uses Lisp
|
||||
addressed as ``you.'' ``The user'' is the person who uses Lisp
|
||||
programs, including those you write.
|
||||
|
||||
@cindex fonts in this manual
|
||||
@ -233,7 +233,7 @@ the examples in this manual, this is indicated with @samp{@result{}}:
|
||||
@end example
|
||||
|
||||
@noindent
|
||||
You can read this as ``@code{(car '(1 2))} evaluates to 1''.
|
||||
You can read this as ``@code{(car '(1 2))} evaluates to 1.''
|
||||
|
||||
When a form is a macro call, it expands into a new form for Lisp to
|
||||
evaluate. We show the result of the expansion with
|
||||
|
@ -2232,7 +2232,7 @@ Next we define the menu items:
|
||||
Note the symbols which the bindings are ``made for''; these appear
|
||||
inside square brackets, in the key sequence being defined. In some
|
||||
cases, this symbol is the same as the command name; sometimes it is
|
||||
different. These symbols are treated as ``function keys'', but they are
|
||||
different. These symbols are treated as ``function keys,'' but they are
|
||||
not real function keys on the keyboard. They do not affect the
|
||||
functioning of the menu itself, but they are ``echoed'' in the echo area
|
||||
when the user selects from the menu, and they appear in the output of
|
||||
|
@ -1503,7 +1503,7 @@ a @sc{cdr} @code{equal} to @var{value}.
|
||||
|
||||
@code{rassoc} is like @code{assoc} except that it compares the @sc{cdr} of
|
||||
each @var{alist} association instead of the @sc{car}. You can think of
|
||||
this as ``reverse @code{assoc}'', finding the key for a given value.
|
||||
this as ``reverse @code{assoc},'' finding the key for a given value.
|
||||
@end defun
|
||||
|
||||
@defun assq key alist
|
||||
@ -1544,7 +1544,7 @@ a @sc{cdr} @code{eq} to @var{value}.
|
||||
|
||||
@code{rassq} is like @code{assq} except that it compares the @sc{cdr} of
|
||||
each @var{alist} association instead of the @sc{car}. You can think of
|
||||
this as ``reverse @code{assq}'', finding the key for a given value.
|
||||
this as ``reverse @code{assq},'' finding the key for a given value.
|
||||
|
||||
For example:
|
||||
|
||||
|
@ -1509,7 +1509,7 @@ the call.
|
||||
This function asks the user a question, expecting input in the echo
|
||||
area. It returns @code{t} if the user types @kbd{y}, @code{nil} if the
|
||||
user types @kbd{n}. This function also accepts @key{SPC} to mean yes
|
||||
and @key{DEL} to mean no. It accepts @kbd{C-]} to mean ``quit'', like
|
||||
and @key{DEL} to mean no. It accepts @kbd{C-]} to mean ``quit,'' like
|
||||
@kbd{C-g}, because the question might look like a minibuffer and for
|
||||
that reason the user might try to use @kbd{C-]} to get out. The answer
|
||||
is a single character, with no @key{RET} needed to terminate it. Upper
|
||||
@ -1699,7 +1699,7 @@ answer); @var{function} is a function of one argument (an object from
|
||||
|
||||
When the user responds with @var{char}, @code{map-y-or-n-p} calls
|
||||
@var{function}. If it returns non-@code{nil}, the object is considered
|
||||
``acted upon'', and @code{map-y-or-n-p} advances to the next object in
|
||||
``acted upon,'' and @code{map-y-or-n-p} advances to the next object in
|
||||
@var{list}. If it returns @code{nil}, the prompt is repeated for the
|
||||
same object.
|
||||
|
||||
|
@ -145,7 +145,7 @@ If @var{function} is already present in @var{hook} (comparing using
|
||||
|
||||
It is best to design your hook functions so that the order in which they
|
||||
are executed does not matter. Any dependence on the order is ``asking
|
||||
for trouble''. However, the order is predictable: normally,
|
||||
for trouble.'' However, the order is predictable: normally,
|
||||
@var{function} goes at the front of the hook list, so it will be
|
||||
executed first (barring another @code{add-hook} call). If the optional
|
||||
argument @var{append} is non-@code{nil}, the new hook function goes at
|
||||
@ -1139,7 +1139,7 @@ it should not use @code{after-change-major-mode-hook} as of yet.
|
||||
|
||||
When you defined a major mode using @code{define-derived-mode}, it
|
||||
automatically makes sure these conventions are followed. If you
|
||||
define a major mode ``from scratch'', not using
|
||||
define a major mode ``from scratch,'' not using
|
||||
@code{define-derived-mode}, make sure the major mode command follows
|
||||
these and other conventions. @xref{Major Mode Conventions}. You use
|
||||
these functions to do it properly.
|
||||
@ -1456,7 +1456,7 @@ See the command \\[hungry-electric-delete]."
|
||||
@end smallexample
|
||||
|
||||
@noindent
|
||||
This defines a minor mode named ``Hungry mode'', a command named
|
||||
This defines a minor mode named ``Hungry mode,'' a command named
|
||||
@code{hungry-mode} to toggle it, a variable named @code{hungry-mode}
|
||||
which indicates whether the mode is enabled, and a variable named
|
||||
@code{hungry-mode-map} which holds the keymap that is active when the
|
||||
|
@ -737,7 +737,7 @@ and returns that value as a floating point number.
|
||||
sequence of @dfn{bits} (digits which are either zero or one). A bitwise
|
||||
operation acts on the individual bits of such a sequence. For example,
|
||||
@dfn{shifting} moves the whole sequence left or right one or more places,
|
||||
reproducing the same pattern ``moved over''.
|
||||
reproducing the same pattern ``moved over.''
|
||||
|
||||
The bitwise operations in Emacs Lisp apply only to integers.
|
||||
|
||||
|
@ -632,7 +632,7 @@ come to refer to any structure made out of cons cells.
|
||||
|
||||
@cindex atom
|
||||
Because cons cells are so central to Lisp, we also have a word for
|
||||
``an object which is not a cons cell''. These objects are called
|
||||
``an object which is not a cons cell.'' These objects are called
|
||||
@dfn{atoms}.
|
||||
|
||||
@cindex parenthesis
|
||||
@ -1238,7 +1238,7 @@ without qualification, we mean a Lisp macro, not a keyboard macro.
|
||||
A @dfn{primitive function} is a function callable from Lisp but
|
||||
written in the C programming language. Primitive functions are also
|
||||
called @dfn{subrs} or @dfn{built-in functions}. (The word ``subr'' is
|
||||
derived from ``subroutine''.) Most primitive functions evaluate all
|
||||
derived from ``subroutine.'') Most primitive functions evaluate all
|
||||
their arguments when they are called. A primitive function that does
|
||||
not evaluate all its arguments is called a @dfn{special form}
|
||||
(@pxref{Special Forms}).@refill
|
||||
|
@ -1839,7 +1839,7 @@ data transmission, but the value is used for calculations such as
|
||||
padding. It also affects decisions about whether to scroll part of the
|
||||
screen or repaint---even when using a window system. (We designed it
|
||||
this way despite the fact that a window system has no true ``output
|
||||
speed'', to give you a way to tune these decisions.)
|
||||
speed,'' to give you a way to tune these decisions.)
|
||||
|
||||
The value is measured in baud.
|
||||
@end defvar
|
||||
|
@ -23,7 +23,7 @@ subprocess, the Lisp program waits for the subprocess to terminate
|
||||
before continuing execution. When you create an asynchronous
|
||||
subprocess, it can run in parallel with the Lisp program. This kind of
|
||||
subprocess is represented within Emacs by a Lisp object which is also
|
||||
called a ``process''. Lisp programs can use this object to communicate
|
||||
called a ``process.'' Lisp programs can use this object to communicate
|
||||
with the subprocess or to control it. For example, you can send
|
||||
signals, obtain status information, receive output from the process, or
|
||||
send input to it.
|
||||
@ -2106,7 +2106,7 @@ processed, and how to pack or unpack it.
|
||||
that the field represents and, in the case of multibyte fields, how
|
||||
the bytes are ordered within the field. The two possible orderings
|
||||
are ``big endian'' (also known as ``network byte ordering'') and
|
||||
``little endian''. For instance, the number @code{#x23cd} (decimal
|
||||
``little endian.'' For instance, the number @code{#x23cd} (decimal
|
||||
9165) in big endian would be the two bytes @code{#x23} @code{#xcd};
|
||||
and in little endian, @code{#xcd} @code{#x23}. Here are the possible
|
||||
type values:
|
||||
|
@ -116,7 +116,7 @@ When it is called with one argument (always a character), @var{function}
|
||||
should save the argument and arrange to return it on the next call.
|
||||
This is called @dfn{unreading} the character; it happens when the Lisp
|
||||
reader reads one character too many and wants to ``put it back where it
|
||||
came from''. In this case, it makes no difference what value
|
||||
came from.'' In this case, it makes no difference what value
|
||||
@var{function} returns.
|
||||
@end itemize
|
||||
|
||||
@ -620,7 +620,7 @@ spacing between calls.
|
||||
@defun terpri &optional stream
|
||||
@cindex newline in print
|
||||
This function outputs a newline to @var{stream}. The name stands
|
||||
for ``terminate print''.
|
||||
for ``terminate print.''
|
||||
@end defun
|
||||
|
||||
@defun write-char character &optional stream
|
||||
|
@ -160,7 +160,7 @@ be customized, use @code{defcustom} (@pxref{Customization}).
|
||||
@code{defun} defines a symbol as a function, creating a lambda
|
||||
expression and storing it in the function cell of the symbol. This
|
||||
lambda expression thus becomes the function definition of the symbol.
|
||||
(The term ``function definition'', meaning the contents of the function
|
||||
(The term ``function definition,'' meaning the contents of the function
|
||||
cell, is derived from the idea that @code{defun} gives the symbol its
|
||||
definition as a function.) @code{defsubst} and @code{defalias} are two
|
||||
other ways of defining a function. @xref{Functions}.
|
||||
|
@ -332,8 +332,8 @@ Emacs supports two comment styles simultaneously in any one syntax
|
||||
table. This is for the sake of C++. Each style of comment syntax has
|
||||
its own comment-start sequence and its own comment-end sequence. Each
|
||||
comment must stick to one style or the other; thus, if it starts with
|
||||
the comment-start sequence of style ``b'', it must also end with the
|
||||
comment-end sequence of style ``b''.
|
||||
the comment-start sequence of style ``b,'' it must also end with the
|
||||
comment-end sequence of style ``b.''
|
||||
|
||||
The two comment-start sequences must begin with the same character; only
|
||||
the second character may differ. Mark the second character of the
|
||||
@ -706,7 +706,7 @@ The minimum parenthesis depth encountered during this scan.
|
||||
@item
|
||||
What kind of comment is active: @code{nil} for a comment of style
|
||||
``a'' or when not inside a comment, @code{t} for a comment of style
|
||||
``b'', and @code{syntax-table} for a comment that should be ended by a
|
||||
``b,'' and @code{syntax-table} for a comment that should be ended by a
|
||||
generic comment delimiter character.
|
||||
|
||||
@item
|
||||
|
@ -702,15 +702,15 @@ use @code{defvar} instead, start the doc string with a @samp{*}.
|
||||
|
||||
@item
|
||||
The documentation string for a variable that is a yes-or-no flag should
|
||||
start with words such as ``Non-nil means@dots{}'', to make it clear that
|
||||
start with words such as ``Non-nil means,'' to make it clear that
|
||||
all non-@code{nil} values are equivalent and indicate explicitly what
|
||||
@code{nil} and non-@code{nil} mean.
|
||||
|
||||
@item
|
||||
The documentation string for a function that is a yes-or-no predicate
|
||||
should start with words such as ``Return t if @dots{}'', to indicate
|
||||
explicitly what constitutes ``truth''. The word ``return'' avoids
|
||||
starting the sentence with lower-case ``t'', which is somewhat
|
||||
should start with words such as ``Return t if,'' to indicate
|
||||
explicitly what constitutes ``truth.'' The word ``return'' avoids
|
||||
starting the sentence with lower-case ``t,'' which could be somewhat
|
||||
distracting.
|
||||
|
||||
@item
|
||||
@ -736,7 +736,7 @@ have the form (KEY . VALUE). Here, KEY is ...
|
||||
|
||||
@item
|
||||
Never change the case of a Lisp symbol when you mention it in a doc
|
||||
string. If the symbol's name is @code{foo}, write ``foo'', not
|
||||
string. If the symbol's name is @code{foo}, write ``foo,'' not
|
||||
``Foo'' (which is a different symbol).
|
||||
|
||||
This might appear to contradict the policy of writing function
|
||||
|
@ -1096,7 +1096,7 @@ is no longer bound to the actual argument 2.
|
||||
@end example
|
||||
|
||||
@cindex closures not available
|
||||
Some Lisp dialects have ``closures'', objects that are like functions
|
||||
Some Lisp dialects have ``closures,'' objects that are like functions
|
||||
but record additional variable bindings. Emacs Lisp does not have
|
||||
closures.
|
||||
|
||||
@ -1459,7 +1459,7 @@ buffer-local variables interactively.
|
||||
|
||||
@defun kill-all-local-variables
|
||||
This function eliminates all the buffer-local variable bindings of the
|
||||
current buffer except for variables marked as ``permanent''. As a
|
||||
current buffer except for variables marked as ``permanent.'' As a
|
||||
result, the buffer will see the default values of most variables.
|
||||
|
||||
This function also resets certain other information pertaining to the
|
||||
|
Loading…
Reference in New Issue
Block a user