xemacs-beta: etc/news.texi comparison

comparison etc/news.texi @ 0:376386a54a3c r19-14

Import from CVS: tag r19-14

author	cvs
date	Mon, 13 Aug 2007 08:45:50 +0200
parents
children	ac2d302a0011

comparison

equal deleted inserted replaced

--1:000000000000
+:376386a54a3c
+\input texinfo    @c -*-texinfo-*-
+@setfilename LNEWS
+This file describes the new Lisp features of Emacs version 19 as first
+released to the public.  For Lisp changes in subsequent Emacs 19
+releases, see the file NEWS.
+@section New Features in the Lisp Language
+@itemize @bullet
+@item
+The new function @code{delete} is a traditional Lisp function.  It takes
+two arguments, @var{elt} and @var{list}, and deletes from @var{list} any
+elements that are equal to @var{elt}.  It uses the function @code{equal}
+to compare elements with @var{elt}.
+@item
+The new function @code{member} is a traditional Lisp function.  It takes
+two arguments, @var{elt} and @var{list}, and finds the first element of
+@var{list} that is equal to @var{elt}.  It uses the function
+@code{equal} to compare each list element with @var{elt}.
+The value is a sublist of @var{list}, whose first element is the one
+that was found.  If no matching element is found, the value is
+@code{nil}.
+@ignore @c Seems not to be true, from looking at the code.
+@item
+The function @code{equal} is now more robust: it does not crash due to
+circular list structure.
+@end ignore
+@item
+The new function @code{indirect-function} finds the effective function
+definition of an object called as a function.  If the object is a
+symbol, @code{indirect-function} looks in the function definition of the
+symbol.  It keeps doing this until it finds something that is not a
+symbol.
+@item
+There are new escape sequences for use in character and string
+constants.  The escape sequence @samp{\a} is equivalent to @samp{\C-g},
+the @sc{ASCII} @sc{BEL} character (code 7).  The escape sequence
+@samp{\x} followed by a hexadecimal number represents the character
+whose @sc{ASCII} code is that number.  There is no limit on the number
+of digits in the hexadecimal value.
+@item
+The function @code{read} when reading from a buffer now does not skip a
+terminator character that terminates a symbol.  It leaves that character
+to be read (or just skipped, if it is whitespace) next time.
+@item
+When you use a function @var{function} as the input stream for
+@code{read}, it is usually called with no arguments, and should return
+the next character.  In Emacs 19, sometimes @var{function} is called
+with one argument (always a character).  When that happens,
+@var{function} should save the argument and arrange to return it when
+called next time.
+@item
+@code{random} with integer argument @var{n} returns a random number
+between 0 and @var{n}@minus{}1.
+@item
+The functions @code{documentation} and @code{documentation-property} now
+take an additional optional argument which, if non-@code{nil}, says to
+refrain from calling @code{substitute-command-keys}.  This way, you get
+the exact text of the documentation string as written, without the usual
+substitutions.  Make sure to call @code{substitute-command-keys}
+yourself if you decide to display the string.
+@item
+The new function @code{invocation-name} returns as a string the program
+name that was used to run Emacs, with any directory names discarded.
+@item
+The new function @code{map-y-or-n-p} makes it convenient to ask a series
+of similar questions.  The arguments are @var{prompter}, @var{actor},
+@var{list}, and optional @var{help}.
+The value of @var{list} is a list of objects, or a function of no
+arguments to return either the next object or @code{nil} meaning there
+are no more.
+The argument @var{prompter} specifies how to ask each question.  If
+@var{prompter} is a string, the question text is computed like this:
+@example
+(format @var{prompter} @var{object})
+@end example
+@noindent
+where @var{object} is the next object to ask about.
+If not a string, @var{prompter} should be a function of one argument
+(the next object to ask about) and should return the question text.
+The argument @var{actor} should be a function of one argument, which is
+called with each object that the user says yes for.  Its argument is
+always one object from @var{list}.
+If @var{help} is given, it is a list @code{(@var{object} @var{objects}
+@var{action})}, where @var{object} is a string containing a singular
+noun that describes the objects conceptually being acted on;
+@var{objects} is the corresponding plural noun and @var{action} is a
+transitive verb describing @var{actor}.  The default is @code{("object"
+"objects" "act on")}.
+Each time a question is asked, the user may enter @kbd{y}, @kbd{Y}, or
+@key{SPC} to act on that object; @kbd{n}, @kbd{N}, or @key{DEL} to skip
+that object; @kbd{!} to act on all following objects; @key{ESC} or
+@kbd{q} to exit (skip all following objects); @kbd{.} (period) to act on
+the current object and then exit; or @kbd{C-h} to get help.
+@code{map-y-or-n-p} returns the number of objects acted on.
+@item
+You can now ``set'' environment variables with the @code{setenv}
+command.  This works by setting the variable @code{process-environment},
+which @code{getenv} now examines in preference to the environment Emacs
+received from its parent.
+@end itemize
+@section New Features for Loading Libraries
+You can now arrange to run a hook if a particular Lisp library is
+loaded.
+The variable @code{after-load-alist} is an alist of expressions to be
+evalled when particular files are loaded.  Each element looks like
+@code{(@var{filename} @var{forms}@dots{})}.
+When @code{load} is run and the file name argument equals
+@var{filename}, the @var{forms} in the corresponding element are
+executed at the end of loading.  @var{filename} must match exactly!
+Normally @var{filename} is the name of a library, with no directory
+specified, since that is how @code{load} is normally called.
+An error in @var{forms} does not undo the load, but does prevent
+execution of the rest of the @var{forms}.
+The function @code{eval-after-load} provides a convenient way to add
+entries to the alist.  Call it with two arguments, @var{file} and a
+form to execute.
+The function @code{autoload} now supports autoloading a keymap.
+Use @code{keymap} as the fourth argument if the autoloaded function
+will become a keymap when loaded.
+There is a new feature for specifying which functions in a library should
+be autoloaded by writing special ``magic'' comments in that library itself.
+Write @samp{;;;###autoload} on a line by itself before the real
+definition of the function, in its autoloadable source file; then the
+command @kbd{M-x update-file-autoloads} automatically puts the
+@code{autoload} call into @file{loaddefs.el}.
+You can also put other kinds of forms into @file{loaddefs.el}, by
+writing @samp{;;;###autoload} followed on the same line by the form.
+@kbd{M-x update-file-autoloads} copies the form from that line.
+@section Compilation Features
+@itemize @bullet
+@item
+Inline functions.
+You can define an @dfn{inline function} with @code{defsubst}.  Use
+@code{defsubst} just like @code{defun}, and it defines a function which
+you can call in all the usual ways.  Whenever the function thus defined
+is used in compiled code, the compiler will open code it.
+You can get somewhat the same effects with a macro, but a macro has the
+limitation that you can use it only explicitly; a macro cannot be called
+with @code{apply}, @code{mapcar} and so on.  Also, it takes some work to
+convert an ordinary function into a macro.  To convert it into an inline
+function, simply replace @code{defun} with @code{defsubst}.
+Making a function inline makes explicit calls run faster.  But it also
+has disadvantages.  For one thing, it reduces flexibility; if you change
+the definition of the function, calls already inlined still use the old
+definition until you recompile them.
+Another disadvantage is that making a large function inline can increase
+the size of compiled code both in files and in memory.  Since the
+advantages of inline functions are greatest for small functions, you
+generally should not make large functions inline.
+Inline functions can be used and open coded later on in the same file,
+following the definition, just like macros.
+@item
+The command @code{byte-compile-file} now offers to save any buffer
+visiting the file you are compiling.
+@item
+The new command @code{compile-defun} reads, compiles and executes the
+defun containing point.  If you use this on a defun that is actually a
+function definition, the effect is to install a compiled version of
+that function.
+@item
+Whenever you load a Lisp file or library, you now receive a warning if
+the directory contains both a @samp{.el} file and a @samp{.elc} file,
+and the @samp{.el} file is newer.  This typically indicates that someone
+has updated the Lisp code but forgotten to recompile it, so the changes
+do not take effect.  The warning is a reminder to recompile.
+@item
+The special form @code{eval-when-compile} marks the forms it contains to
+be evaluated at compile time @emph{only}.  At top-level, this is
+analogous to the Common Lisp idiom @code{(eval-when (compile)
+@dots{})}.  Elsewhere, it is similar to the Common Lisp @samp{#.} reader
+macro (but not when interpreting).
+If you're thinking of using this feature, we recommend you consider whether
+@code{provide} and @code{require} might do the job as well.
+@item
+The special form @code{eval-and-compile} is similar to
+@code{eval-when-compile}, but the whole form is evaluated both at
+compile time and at run time.
+If you're thinking of using this feature, we recommend you consider
+whether @code{provide} and @code{require} might do the job as well.
+@item
+Emacs Lisp has a new data type for byte-code functions.  This makes
+them faster to call, and also saves space.  Internally, a byte-code
+function object is much like a vector; however, the evaluator handles
+this data type specially when it appears as a function to be called.
+The printed representation for a byte-code function object is like that
+for a vector, except that it starts with @samp{#} before the opening
+@samp{[}.  A byte-code function object must have at least four elements;
+there is no maximum number, but only the first six elements are actually
+used.  They are:
+@table @var
+@item arglist
+The list of argument symbols.
+@item byte-code
+The string containing the byte-code instructions.
+@item constants
+The vector of constants referenced by the byte code.
+@item stacksize
+The maximum stack size this function needs.
+@item docstring
+The documentation string (if any); otherwise, @code{nil}.
+@item interactive
+The interactive spec (if any).  This can be a string or a Lisp
+expression.  It is @code{nil} for a function that isn't interactive.
+@end table
+The predicate @code{byte-code-function-p} tests whether a given object
+is a byte-code function.
+You can create a byte-code function object in a Lisp program
+with the function @code{make-byte-code}.  Its arguments are the elements
+to put in the byte-code function object.
+You should not try to come up with the elements for a byte-code function
+yourself, because if they are inconsistent, Emacs may crash when you
+call the function.  Always leave it to the byte compiler to create these
+objects; it, we hope, always makes the elements consistent.
+@end itemize
+@section Floating Point Numbers
+You can now use floating point numbers in Emacs, if you define the macro
+@code{LISP_FLOAT_TYPE} when you compile Emacs.
+The printed representation for floating point numbers requires either a
+decimal point surrounded by digits, or an exponent, or both.  For
+example, @samp{1500.0}, @samp{15e2}, @samp{15.0e2} and @samp{1.5e3} are
+four ways of writing a floating point number whose value is 1500.
+The existing predicate @code{numberp} now returns @code{t} if the
+argument is any kind of number---either integer or floating.  The new
+predicates @code{integerp} and @code{floatp} check for specific types of
+numbers.
+You can do arithmetic on floating point numbers with the ordinary
+arithmetic functions, @code{+}, @code{-}, @code{*} and @code{/}.  If you
+call one of these functions with both integers and floating point
+numbers among the arguments, the arithmetic is done in floating point.
+The same applies to the numeric comparison functions such as @code{=}
+and @code{<}.  The remainder function @code{%} does not accept floating
+point arguments, and neither do the bitwise boolean operations such as
+@code{logand} or the shift functions such as @code{ash}.
+There is a new arithmetic function, @code{abs}, which returns the absolute
+value of its argument.  It handles both integers and floating point
+numbers.
+To convert an integer to floating point, use the function @code{float}.
+There are four functions to convert floating point numbers to integers;
+they differ in how they round.  @code{truncate} rounds toward 0,
+@code{floor} rounds down, @code{ceil} rounds up, and @code{round}
+produces the nearest integer.
+You can use @code{logb} to extract the binary exponent of a floating
+point number.  More precisely, it is the logarithm base 2, rounded down
+to an integer.
+Emacs has several new mathematical functions that accept any kind of
+number as argument, but always return floating point numbers.
+@table @code
+@item cos
+@findex cos
+@itemx sin
+@findex sin
+@itemx tan
+@findex tan
+Trigonometric functions.
+@item acos
+@findex acos
+@itemx asin
+@findex asin
+@itemx atan
+@findex atan
+Inverse trigonometric functions.
+@item exp
+@findex exp
+The exponential function (power of @var{e}).
+@item log
+@findex log
+Logarithm base @var{e}.
+@item log10
+@findex log10
+Logarithm base 10
+@item expt
+@findex expt
+Raise @var{x} to power @var{y}.
+@item sqrt
+@findex sqrt
+The square root function.
+@end table
+The new function @code{string-to-number} now parses a string containing
+either an integer or a floating point number, returning the number.
+The @code{format} function now handles the specifications @samp{%e},
+@samp{%f} and @samp{%g} for printing floating point numbers; likewise
+@code{message}.
+The new variable @code{float-output-format} controls how Lisp prints
+floating point numbers.  Its value should be @code{nil} or a string.
+If it is a string, it should contain a @samp{%}-spec like those accepted
+by @code{printf} in C, but with some restrictions.  It must start with
+the two characters @samp{%.}.  After that comes an integer which is the
+precision specification, and then a letter which controls the format.
+The letters allowed are @samp{e}, @samp{f} and @samp{g}.  Use @samp{e}
+for exponential notation (@samp{@var{dig}.@var{digits}e@var{expt}}).
+Use @samp{f} for decimal point notation
+(@samp{@var{digits}.@var{digits}}).  Use @samp{g} to choose the shorter
+of those two formats for the number at hand.
+The precision in any of these cases is the number of digits following
+the decimal point.  With @samp{e}, a precision of 0 means to omit the
+decimal point.  0 is not allowed with @samp{f} or @samp{g}.
+A value of @code{nil} means to use the format @samp{%.20g}.
+No matter what the value of @code{float-output-format}, printing ensures
+that the result fits the syntax rules for a floating point number.  If
+it doesn't fit (for example, if it looks like an integer), it is
+modified to fit.  By contrast, the @code{format} function formats
+floating point numbers without requiring the output to fit the
+syntax rules for floating point number.
+@section New Features for Printing And Formatting Output
+@itemize @bullet
+@item
+The @code{format} function has a new feature: @samp{%S}.  This print
+spec prints any kind of Lisp object, even a string, using its Lisp
+printed representation.
+By contrast, @samp{%s} prints everything without quotation.
+@item
+@code{prin1-to-string} now takes an optional second argument which says
+not to print the Lisp quotation characters.  (In other words, to use
+@code{princ} instead of @code{prin1}.)
+@item
+The new variable @code{print-level} specifies the maximum depth of list
+nesting to print before cutting off all deeper structure.  A value of
+@code{nil} means no limit.
+@end itemize
+@section Changes in Basic Editing Functions
+@itemize @bullet
+@item
+There are two new primitives for putting text in the kill ring:
+@code{kill-new} and @code{kill-append}.
+The function @code{kill-new} adds a string to the front of the kill ring.
+Use @code{kill-append} to add a string to a previous kill.  The second
+argument @var{before-p}, if non-@code{nil}, says to add the string at
+the beginning; otherwise, it goes at the end.
+Both of these functions apply @code{interprogram-cut-function} to the
+entire string of killed text that ends up at the beginning of the kill
+ring.
+@item
+The new function @code{current-kill} rotates the yanking pointer in the
+kill ring by @var{n} places, and returns the text at that place in the
+ring.  If the optional second argument @var{do-not-move} is
+non-@code{nil}, it doesn't actually move the yanking point; it just
+returns the @var{n}th kill forward.  If @var{n} is zero, indicating a
+request for the latest kill, @code{current-kill} calls
+@code{interprogram-paste-function} (documented below) before consulting
+the kill ring.
+All Emacs Lisp programs should either use @code{current-kill},
+@code{kill-new}, and @code{kill-append} to manipulate the kill ring, or
+be sure to call @code{interprogram-paste-function} and
+@code{interprogram-cut-function} as appropriate.
+@item
+The variables @code{interprogram-paste-function} and
+@code{interprogram-cut-function} exist so that you can provide functions
+to transfer killed text to and from other programs.
+@item
+The @code{kill-region} function can now be used in read-only buffers.
+It beeps, but adds the region to the kill ring without deleting it.
+@item
+The new function @code{compare-buffer-substrings} lets you compare two
+substrings of the same buffer or two different buffers.  Its arguments
+look like this:
+@example
+(compare-buffer-substrings @var{buf1} @var{beg1} @var{end1} @var{buf2} @var{beg2} @var{end2})
+@end example
+The first three arguments specify one substring, giving a buffer and two
+positions within the buffer.  The last three arguments specify the other
+substring in the same way.
+The value is negative if the first substring is less, positive if the
+first is greater, and zero if they are equal.  The absolute value of
+the result is one plus the index of the first different characters.
+@item
+Overwrite mode treats tab and newline characters specially.  You can now
+turn off this special treatment by setting @code{overwrite-binary-mode}
+to @code{t}.
+@item
+Once the mark ``exists'' in a buffer, it normally never ceases to
+exist.  However, in Transient Mark mode, it may become @dfn{inactive}.
+The variable @code{mark-active}, which is always local in all buffers,
+indicates whether the mark is active: non-@code{nil} means yes.
+When the mark is inactive, the function @code{mark} normally gets an
+error.  However, @code{(mark t)} returns the position of the inactive
+mark.
+The function @code{push-mark} normally does not activate the mark.
+However, it accepts an optional third argument @var{activate} which,
+if non-@code{nil}, says to activate.
+A command can request deactivation of the mark upon return to the editor
+command loop by setting @code{deactivate-mark} to a non-@code{nil}
+value.  Transient Mark mode works by causing the command loop to take
+note of @code{deactivate-mark} and actually deactivate the mark.
+Transient Mark mode enables highlighting of the region when the mark is
+active.  This is currently implemented only under the X Window System.
+A few other commands vary their behavior slightly in this case, by
+testing @code{transient-mark-mode}.  More specifically, they avoid
+special display actions such as moving the cursor temporarily, which are
+not needed when the region is shown by highlighting.
+The variables @code{activate-mark-hook} and @code{deactivate-mark-hook}
+are normal hooks run, respectively, when the mark becomes active and when
+it becomes inactive.  The hook @code{activate-mark-hook} is also run at
+the end of a command if the mark is active and the region may have
+changed.
+@item
+The function @code{move-to-column} now accepts a second optional
+argument @var{force}, in addition to @var{column}; if the requested
+column @var{column} is in the middle of a tab character and @var{force}
+is non-@code{nil}, @code{move-to-column} replaces the tab with the
+appropriate sequence of spaces so that it can place point exactly at
+@var{column}.
+@item
+The search functions when successful now return the value of point
+rather than just @code{t}.  This affects the functions
+@code{search-forward}, @code{search-backward},
+@code{word-search-forward}, @code{word-search-backward},
+@code{re-search-forward}, and @code{re-search-backward}.
+@item
+When you do regular expression searching or matching, there is no longer
+a limit to how many @samp{\(@dots{}\)} pairs you can get information
+about with @code{match-beginning} and @code{match-end}.  Also, these
+parenthetical groupings may now be nested to any degree.
+@item
+In a regular expression, when you use an asterisk after a parenthetical
+grouping, and then ask about what range was matched by the grouping,
+Emacs 19 reports just its last occurrence.  Emacs 18 used to report the
+range of all the repetitions put together.
+For example,
+@example
+(progn
+(string-match "f\\(o\\)*" "foo")
+(list (match-beginning 1)
+(match-end 1)))
+@end example
+@noindent
+returns @code{(2 3)} in Emacs 19, corresponding to just the last
+repetition of @samp{\(o\)}.  In Emacs 18, that expression returns
+@code{(1 3)}, encompassing both repetitions.
+If you want the Emacs 18 behavior, use a grouping @emph{containing} the
+asterisk: @code{"f\\(o*\\)"}.
+@item
+The new special form @code{save-match-data} preserves the regular
+expression match status.  Usage: @code{(save-match-data
+@var{body}@dots{})}.
+@item
+The function @code{translate-region} applies a translation table to the
+characters in a part of the buffer.  Invoke it as
+@code{(translate-region @var{start} @var{end} @var{table})}; @var{start}
+and @var{end} bound the region to translate.
+The translation table @var{table} is a string; @code{(aref @var{table}
+@var{ochar})} gives the translated character corresponding to
+@var{ochar}.  If the length of @var{table} is less than 256, any
+characters with codes larger than the length of @var{table} are not
+altered by the translation.
+@code{translate-region} returns the number of characters which were
+actually changed by the translation.  This does not count characters
+which were mapped into themselves in the translation table.
+@item
+There are two new hook variables that let you notice all changes in all
+buffers (or in a particular buffer, if you make them buffer-local):
+@code{before-change-function} and @code{after-change-function}.
+If @code{before-change-function} is non-@code{nil}, then it is called
+before any buffer modification.  Its arguments are the beginning and end
+of the region that is going to change, represented as integers.  The
+buffer that's about to change is always the current buffer.
+If @code{after-change-function} is non-@code{nil}, then it is called
+after any buffer modification.  It takes three arguments: the beginning
+and end of the region just changed, and the length of the text that
+existed before the change.  (To get the current length, subtract the
+region beginning from the region end.)  All three arguments are
+integers.  The buffer that has just changed is always the current
+buffer.
+Both of these variables are temporarily bound to @code{nil} during the
+time that either of these hooks is running.  This means that if one of
+these functions changes the buffer, that change won't run these
+functions.  If you do want hooks to be run recursively, write your hook
+functions to bind these variables back to their usual values.
+@item
+The hook @code{first-change-hook} is run using @code{run-hooks} whenever
+a buffer is changed that was previously in the unmodified state.
+@item
+The second argument to @code{insert-abbrev-table-description} is
+now optional.
+@end itemize
+@section Text Properties
+Each character in a buffer or a string can have a @dfn{text property
+list}, much like the property list of a symbol.  The properties belong
+to a particular character at a particular place, such as, the letter
+@samp{T} at the beginning of this sentence.  Each property has a name,
+which is usually a symbol, and an associated value, which can be any
+Lisp object---just as for properties of symbols.
+You can use the property @code{face} to control the font and
+color of text.  Several other property names have special meanings.  You
+can create properties of any name and examine them later for your own
+purposes.
+Copying text between strings and buffers preserves the properties
+along with the characters; this includes such diverse functions as
+@code{substring}, @code{insert}, and @code{buffer-substring}.
+Since text properties are considered part of the buffer contents,
+changing properties in a buffer ``modifies'' the buffer, and you can
+also undo such changes.
+Strings with text properties have a special printed representation
+which describes all the properties.  This representation is also the
+read syntax for such a string.  It looks like this:
+@example
+#("@var{characters}" @var{property-data}...)
+@end example
+@noindent
+where @var{property-data} is zero or more elements in groups of three as
+follows:
+@example
+@var{beg} @var{end} @var{plist}
+@end example
+@noindent
+The elements @var{beg} and @var{end} are integers, and together specify
+a portion of the string; @var{plist} is the property list for that
+portion.
+@subsection Examining Text Properties
+The simplest way to examine text properties is to ask for the value of
+a particular property of a particular character.  For that, use
+@code{get-text-property}.  Use @code{text-properties-at} to get the
+entire property list of a character.
+@code{(get-text-property @var{pos} @var{prop} @var{object})} returns the
+@var{prop} property of the character after @var{pos} in @var{object} (a
+buffer or string).  The argument @var{object} is optional and defaults
+to the current buffer.
+@code{(text-properties-at @var{pos} @var{object})} returns the entire
+property list of the character after @var{pos} in the string or buffer
+@var{object} (which defaults to the current buffer).
+@subsection Changing Text Properties
+There are four primitives for changing properties of a specified
+range of text:
+@table @code
+@item add-text-properties
+This function puts on specified properties, leaving other existing
+properties unaltered.
+@item put-text-property
+This function puts on a single specified property, leaving others
+unaltered.
+@item remove-text-properties
+This function removes specified properties, leaving other
+properties unaltered.
+@item set-text-properties
+This function replaces the entire property list, leaving no vestige of
+the properties that that text used to have.
+@end table
+All these functions take four arguments: @var{start}, @var{end},
+@var{props}, and @var{object}.  The last argument is optional and
+defaults to the current buffer.  The argument @var{props} has the form
+of a property list.
+@subsection Property Search Functions
+In typical use of text properties, most of the time several or many
+consecutive characters have the same value for a property.  Rather than
+writing your programs to examine characters one by one, it is much
+faster to process chunks of text that have the same property value.
+The functions @code{next-property-change} and
+@code{previous-property-change} scan forward or backward from position
+@var{pos} in @var{object}, looking for a change in any property between
+two characters scanned.  They returns the position between those two
+characters, or @code{nil} if no change is found.
+The functions @code{next-single-property-change} and
+@code{previous-single-property-change} are similar except that you
+specify a particular property and they look for changes in the value of
+that property only.  The property is the second argument, and
+@var{object} is third.
+@subsection Special Properties
+If a character has a @code{category} property, we call it the
+@dfn{category} of the character.  It should be a symbol.  The properties
+of the symbol serve as defaults for the properties of the character.
+You can use the property @code{face} to control the font and
+color of text.
+You can specify a different keymap for a portion of the text by means
+of a @code{local-map} property.  The property's value, for the character
+after point, replaces the buffer's local map.
+If a character has the property @code{read-only}, then modifying that
+character is not allowed.  Any command that would do so gets an error.
+If a character has the property @code{modification-hooks}, then its
+value should be a list of functions; modifying that character calls all
+of those functions.  Each function receives two arguments: the beginning
+and end of the part of the buffer being modified.  Note that if a
+particular modification hook function appears on several characters
+being modified by a single primitive, you can't predict how many times
+the function will be called.
+Insertion of text does not, strictly speaking, change any existing
+character, so there is a special rule for insertion.  It compares the
+@code{read-only} properties of the two surrounding characters; if they
+are @code{eq}, then the insertion is not allowed.  Assuming insertion is
+allowed, it then gets the @code{modification-hooks} properties of those
+characters and calls all the functions in each of them.  (If a function
+appears on both characters, it may be called once or twice.)
+The special properties @code{point-entered} and @code{point-left}
+record hook functions that report motion of point.  Each time point
+moves, Emacs compares these two property values:
+@itemize @bullet
+@item
+the @code{point-left} property of the character after the old location,
+and
+@item
+the @code{point-entered} property of the character after the new
+location.
+@end itemize
+@noindent
+If these two values differ, each of them is called (if not @code{nil})
+with two arguments: the old value of point, and the new one.
+The same comparison is made for the characters before the old and new
+locations.  The result may be to execute two @code{point-left} functions
+(which may be the same function) and/or two @code{point-entered}
+functions (which may be the same function).  The @code{point-left}
+functions are always called before the @code{point-entered} functions.
+A primitive function may examine characters at various positions
+without moving point to those positions.  Only an actual change in the
+value of point runs these hook functions.
+@section New Features for Files
+@itemize @bullet
+@item
+The new function @code{file-accessible-directory-p} tells you whether
+you can open files in a particular directory.  Specify as an argument
+either a directory name or a file name which names a directory file.
+The function returns @code{t} if you can open existing files in that
+directory.
+@item
+The new function @code{file-executable-p} returns @code{t} if its
+argument is the name of a file you have permission to execute.
+@item
+The function @code{file-truename} returns the ``true name'' of a
+specified file.  This is the name that you get by following symbolic
+links until none remain.  The argument must be an absolute file name.
+@item
+New functions @code{make-directory} and @code{delete-directory} create and
+delete directories.  They both take one argument, which is the name of
+the directory as a file.
+@item
+The function @code{read-file-name} now takes an additional argument
+which specifies an initial file name.  If you specify this argument,
+@code{read-file-name} inserts it along with the directory name.  It puts
+the cursor between the directory and the initial file name.
+The user can then use the initial file name unchanged, modify it, or
+simply kill it with @kbd{C-k}.
+If the variable @code{insert-default-directory} is @code{nil}, then the
+default directory is not inserted, and the new argument is ignored.
+@item
+The function @code{file-relative-name} does the inverse of
+expansion---it tries to return a relative name which is equivalent to
+@var{filename} when interpreted relative to @var{directory}.  (If such a
+relative name would be longer than the absolute name, it returns the
+absolute name instead.)
+@item
+The function @code{file-newest-backup} returns the name of the most
+recent backup file for @var{filename}, or @code{nil} that file has no
+backup files.
+@item
+The list returned by @code{file-attributes} now has 12 elements.  The
+12th element is the file system number of the file system that the file
+is in.  This element together with the file's inode number, which is the
+11th element, give enough information to distinguish any two files on
+the system---no two files can have the same values for both of these
+numbers.
+@item
+The new function @code{set-visited-file-modtime} updates the current
+buffer's recorded modification time from the visited file's time.
+This is useful if the buffer was not read from the file normally, or
+if the file itself has been changed for some known benign reason.
+If you give the function an argument, that argument specifies the new
+value for the recorded modification time.  The argument should be a list
+of the form @code{(@var{high} . @var{low})} or @code{(@var{high}
+@var{low})} containing two integers, each of which holds 16 bits of the
+time.  (This is the same format that @code{file-attributes} uses to
+return time values.)
+The new function @code{visited-file-modtime} returns the recorded last
+modification time, in that same format.
+@item
+The function @code{directory-files} now takes an optional fourth
+argument which, if non-@code{nil}, inhibits sorting the file names.
+Use this if you want the utmost possible speed and don't care what order
+the files are processed in.
+If the order of processing is at all visible to the user, then the user
+will probably be happier if you do sort the names.
+@item
+The variable @code{directory-abbrev-alist} contains an alist of
+abbreviations to use for file directories.  Each element has the form
+@code{(@var{from} . @var{to})}, and says to replace @var{from} with
+@var{to} when it appears in a directory name.  This replacement is done
+when setting up the default directory of a newly visited file.  The
+@var{from} string is actually a regular expression; it should always
+start with @samp{^}.
+You can set this variable in @file{site-init.el} to describe the
+abbreviations appropriate for your site.
+@item
+The function @code{abbreviate-file-name} applies abbreviations from
+@code{directory-abbrev-alist} to its argument, and substitutes @samp{~}
+for the user's home directory.
+Abbreviated directory names are useful for directories that are normally
+accessed through symbolic links.  If you think of the link's name as
+``the name'' of the directory, you can define it as an abbreviation for
+the directory's official name; then ordinarily Emacs will call that
+directory by the link name you normally use.
+@item
+@code{write-region} can write a given string instead of text from the
+buffer.  Use the string as the first argument (in place of the
+starting character position).
+You can supply a second file name as the fifth argument (@var{visit}).
+Use this to write the data to one file (the first argument,
+@var{filename}) while nominally visiting a different file (the fifth
+argument, @var{visit}).  The argument @var{visit} is used in the echo
+area message and also for file locking; @var{visit} is stored in
+@code{buffer-file-name}.
+@item
+The value of @code{write-file-hooks} does not change when you switch to
+a new major mode.  The intention is that these hooks have to do with
+where the file came from, and not with what it contains.
+@item
+There is a new hook variable for saving files:
+@code{write-contents-hooks}.  It works just like @code{write-file-hooks}
+except that switching to a new major mode clears it back to @code{nil}.
+Major modes should use this hook variable rather than
+@code{write-file-hooks}.
+@item
+The hook @code{after-save-buffer-hook} runs just after a buffer has been
+saved in its visited file.
+@item
+The new function @code{set-default-file-modes} sets the file protection
+for new files created with Emacs.  The argument must be an integer.  (It
+would be better to permit symbolic arguments like the @code{chmod}
+program, but that would take more work than this function merits.)
+Use the new function @code{default-file-modes} to read the current
+default file mode.
+@item
+Call the new function @code{unix-sync} to force all pending disk output
+to happen as soon as possible.
+@end itemize
+@section Making Certain File Names ``Magic''
+You can implement special handling for a class of file names.  You must
+supply a regular expression to define the class of names (all those
+which match the regular expression), plus a handler that implements all
+the primitive Emacs file operations for file names that do match.
+The value of @code{file-name-handler-alist} is a list of handlers,
+together with regular expressions that decide when to apply each
+handler.  Each element has the form @code{(@var{regexp}
+. @var{handler})}.  If a file name matches @var{regexp}, then all work
+on that file is done by calling @var{handler}.
+All the Emacs primitives for file access and file name transformation
+check the given file name against @code{file-name-handler-alist}, and
+call @var{handler} to do the work if appropriate.  The first argument
+given to @var{handler} is the name of the primitive; the remaining
+arguments are the arguments that were passed to that primitive.  (The
+first of these arguments is typically the file name itself.)  For
+example, if you do this:
+@example
+(file-exists-p @var{filename})
+@end example
+@noindent
+and @var{filename} has handler @var{handler}, then @var{handler} is
+called like this:
+@example
+(funcall @var{handler} 'file-exists-p @var{filename})
+@end example
+Here are the primitives that you can handle in this way:
+@quotation
+@code{add-name-to-file}, @code{copy-file}, @code{delete-directory},
+@code{delete-file}, @code{directory-file-name}, @code{directory-files},
+@code{dired-compress-file}, @code{dired-uncache},
+@code{expand-file-name}, @code{file-accessible-directory-p},
+@code{file-attributes}, @code{file-directory-p},
+@code{file-executable-p}, @code{file-exists-p}, @code{file-local-copy},
+@code{file-modes}, @code{file-name-all-completions},
+@code{file-name-as-directory}, @code{file-name-completion},
+@code{file-name-directory}, @code{file-name-nondirectory},
+@code{file-name-sans-versions}, @code{file-newer-than-file-p},
+@code{file-readable-p}, @code{file-symlink-p}, @code{file-writable-p},
+@code{insert-directory}, @code{insert-file-contents}, @code{load},
+@code{make-directory}, @code{make-symbolic-link}, @code{rename-file},
+@code{set-file-modes}, @code{set-visited-file-modtime},
+@code{unhandled-file-name-directory},
+@code{verify-visited-file-modtime}, @code{write-region}.
+@end quotation
+The handler function must handle all of the above operations, and
+possibly others to be added in the future.  Therefore, it should always
+reinvoke the ordinary Lisp primitive when it receives an operation it
+does not recognize.  Here's one way to do this:
+@smallexample
+(defun my-file-handler (operation &rest args)
+;; @r{First check for the specific operations}
+;; @r{that we have special handling for.}
+(cond ((eq operation 'insert-file-contents) @dots{})
+((eq operation 'write-region) @dots{})
+@dots{}
+;; @r{Handle any operation we don't know about.}
+(t (let (file-name-handler-alist)
+(apply operation args)))))
+@end smallexample
+The function @code{file-local-copy} copies file @var{filename} to the
+local site, if it isn't there already.  If @var{filename} specifies a
+``magic'' file name which programs outside Emacs cannot directly read or
+write, this copies the contents to an ordinary file and returns that
+file's name.
+If @var{filename} is an ordinary file name, not magic, then this function
+does nothing and returns @code{nil}.
+The function @code{unhandled-file-name-directory} is used to get a
+non-magic directory name from an arbitrary file name.  It uses the
+directory part of the specified file name if that is not magic.
+Otherwise, it asks the file name's handler what to do.
+@section Frames
+@cindex frame
+Emacs now supports multiple X windows via a new data type known as a
+@dfn{frame}.
+A frame is a rectangle on the screen that contains one or more Emacs
+windows.  Subdividing a frame works just like subdividing the screen in
+earlier versions of Emacs.
+@cindex terminal frame
+There are two kinds of frames: terminal frames and X window frames.
+Emacs creates one terminal frame when it starts up with no X display; it
+uses Termcap or Terminfo to display using characters.  There is no way
+to create another terminal frame after startup.  If Emacs has an X
+display, it does not make a terminal frame, and there is none.
+@cindex X window frame
+When you are using X windows, Emacs starts out with a single X window
+frame.  You can create any number of X window frames using
+@code{make-frame}.
+Use the predicate @code{framep} to determine whether a given Lisp object
+is a frame.
+The function @code{redraw-frame} redisplays the entire contents of a
+given frame.
+@subsection Creating and Deleting Frames
+Use @code{make-frame} to create a new frame.  This is the only primitive
+for creating frames.  In principle it could work under any window system
+which Emacs understands; the only one we support is X.
+@code{make-frame} takes just one argument, which is an alist
+specifying frame parameters.  Any parameters not mentioned in the
+argument alist default based on the value of @code{default-frame-alist};
+parameters not specified there default from the standard X defaults file
+and X resources.
+When you invoke Emacs, if you specify arguments for window appearance
+and so forth, these go into @code{default-frame-alist} and that is how
+they have their effect.
+You can specify the parameters for the initial startup X window frame by
+setting @code{initial-frame-alist} in your @file{.emacs} file.  If these
+parameters specify a separate minibuffer-only frame, and you have not
+created one, Emacs creates one for you, using the parameter values
+specified in @code{minibuffer-frame-alist}.
+You can specify the size and position of a frame using the frame
+parameters @code{left}, @code{top}, @code{height} and @code{width}.  You
+must specify either both size parameters or neither.  You must specify
+either both position parameters or neither.  The geometry parameters
+that you don't specify are chosen by the window manager in its usual
+fashion.
+The function @code{x-parse-geometry} converts a standard X-style
+geometry string to an alist which you can use as part of the argument to
+@code{make-frame}.
+Use the function @code{delete-frame} to eliminate a frame.  Frames are
+like buffers where deletion is concerned; a frame actually continues to
+exist as a Lisp object until it is deleted @emph{and} there are no
+references to it, but once it is deleted, it has no further effect on
+the screen.
+The function @code{frame-live-p} returns non-@code{nil} if the argument
+(a frame) has not been deleted.
+@subsection Finding All Frames
+The function @code{frame-list} returns a list of all the frames that have
+not been deleted.  It is analogous to @code{buffer-list}.  The list that
+you get is newly created, so modifying the list doesn't have any effect
+on the internals of Emacs.  The function @code{visible-frame-list} returns
+the list of just the frames that are visible.
+@code{next-frame} lets you cycle conveniently through all the frames from an
+arbitrary starting point.  Its first argument is a frame.  Its second
+argument @var{minibuf} says what to do about minibuffers:
+@table @asis
+@item @code{nil}
+Exclude minibuffer-only frames.
+@item a window
+Consider only the frames using that particular window as their
+minibuffer.
+@item anything else
+Consider all frames.
+@end table
+@subsection Frames and Windows
+All the non-minibuffer windows in a frame are arranged in a tree of
+subdivisions; the root of this tree is available via the function
+@code{frame-root-window}.  Each window is part of one and only one
+frame; you can get the frame with @code{window-frame}.
+At any time, exactly one window on any frame is @dfn{selected within the
+frame}.  You can get the frame's current selected window with
+@code{frame-selected-window}.  The significance of this designation is
+that selecting the frame selects for Emacs as a whole the window
+currently selected within that frame.
+Conversely, selecting a window for Emacs with @code{select-window} also
+makes that window selected within its frame.
+@subsection Frame Visibility
+A frame may be @dfn{visible}, @dfn{invisible}, or @dfn{iconified}.  If
+it is invisible, it doesn't show in the screen, not even as an icon.
+You can set the visibility status of a frame with
+@code{make-frame-visible}, @code{make-frame-invisible}, and
+@code{iconify-frame}.  You can examine the visibility status with
+@code{frame-visible-p}---it returns @code{t} for a visible frame,
+@code{nil} for an invisible frame, and @code{icon} for an iconified
+frame.
+@subsection Selected Frame
+At any time, one frame in Emacs is the @dfn{selected frame}.  The selected
+window always resides on the selected frame.
+@defun selected-frame
+This function returns the selected frame.
+@end defun
+The X server normally directs keyboard input to the X window that the
+mouse is in.  Some window managers use mouse clicks or keyboard events
+to @dfn{shift the focus} to various X windows, overriding the normal
+behavior of the server.
+Lisp programs can switch frames ``temporarily'' by calling the function
+@code{select-frame}.  This does not override the window manager; rather,
+it escapes from the window manager's control until that control is
+somehow reasserted.  The function takes one argument, a frame, and
+selects that frame.  The selection lasts until the next time the user
+does something to select a different frame, or until the next time this
+function is called.
+Emacs cooperates with the X server and the window managers by arranging
+to select frames according to what the server and window manager ask
+for.  It does so by generating a special kind of input event, called a
+@dfn{focus} event.  The command loop handles a focus event by calling
+@code{internal-select-frame}.
+@subsection Frame Size and Position
+The new functions @code{frame-height} and @code{frame-width} return the
+height and width of a specified frame (or of the selected frame),
+measured in characters.
+The new functions @code{frame-pixel-height} and @code{frame-pixel-width}
+return the height and width of a specified frame (or of the selected
+frame), measured in pixels.
+The new functions @code{frame-char-height} and @code{frame-char-width}
+return the height and width of a character in a specified frame (or in
+the selected frame), measured in pixels.
+@code{set-frame-size} sets the size of a frame, measured in characters;
+its arguments are @var{frame}, @var{cols} and @var{rows}.  To set the
+size with values measured in pixels, you can use
+@code{modify-frame-parameters}.
+The function @code{set-frame-position} sets the position of the top left
+corner of a frame.  Its arguments are @var{frame}, @var{left} and
+@var{top}.
+@ignore
+New functions @code{set-frame-height} and @code{set-frame-width} set the
+size of a specified frame.  The frame is the first argument; the size is
+the second.
+@end ignore
+@subsection Frame Parameters
+A frame has many parameters that affect how it displays.  Use the
+function @code{frame-parameters} to get an alist of all the parameters
+of a given frame.  To alter parameters, use
+@code{modify-frame-parameters}, which takes two arguments: the frame to
+modify, and an alist of parameters to change and their new values.  Each
+element of @var{alist} has the form @code{(@var{parm} . @var{value})},
+where @var{parm} is a symbol.  Parameters that aren't meaningful are
+ignored.  If you don't mention a parameter in @var{alist}, its value
+doesn't change.
+Just what parameters a frame has depends on what display mechanism it
+uses.  Here is a table of the parameters of an X
+window frame:
+@table @code
+@item name
+The name of the frame.
+@item left
+The screen position of the left edge.
+@item top
+The screen position of the top edge.
+@item height
+The height of the frame contents, in pixels.
+@item width
+The width of the frame contents, in pixels.
+@item window-id
+The number of the X window for the frame.
+@item minibuffer
+Whether this frame has its own minibuffer.
+@code{t} means yes, @code{none} means no,
+@code{only} means this frame is just a minibuffer,
+a minibuffer window (in some other frame)
+means the new frame uses that minibuffer.
+@item font
+The name of the font for the text.
+@item foreground-color
+The color to use for the inside of a character.
+Use strings to designate colors;
+the X server defines the meaningful color names.
+@item background-color
+The color to use for the background of text.
+@item mouse-color
+The color for the mouse cursor.
+@item cursor-color
+The color for the cursor that shows point.
+@item border-color
+The color for the border of the frame.
+@item cursor-type
+The way to display the cursor.  There are two legitimate values:
+@code{bar} and @code{box}.  The value @code{bar} specifies a vertical
+bar between characters as the cursor.  The value @code{box} specifies an
+ordinary black box overlaying the character after point; that is the
+default.
+@item icon-type
+Non-@code{nil} for a bitmap icon, @code{nil} for a text icon.
+@item border-width
+The width in pixels of the window border.
+@item internal-border-width
+The distance in pixels between text and border.
+@item auto-raise
+Non-@code{nil} means selecting the frame raises it.
+@item auto-lower
+Non-@code{nil} means deselecting the frame lowers it.
+@item vertical-scroll-bars
+Non-@code{nil} gives the frame a scroll bar
+for vertical scrolling.
+@ignore
+@item horizontal-scroll-bars
+Non-@code{nil} gives the frame a scroll bar
+for horizontal scrolling.
+@end ignore
+@end table
+@subsection Minibufferless Frames
+Normally, each frame has its own minibuffer window at the bottom, which
+is used whenever that frame is selected.  However, you can also create
+frames with no minibuffers.  These frames must use the minibuffer window
+of some other frame.
+The variable @code{default-minibuffer-frame} specifies where to find a
+minibuffer for frames created without minibuffers of their own.  Its
+value should be a frame which does have a minibuffer.
+You can also specify a minibuffer window explicitly when you create a
+frame; then @code{default-minibuffer-frame} is not used.
+@section X Window System Features
+@itemize @bullet
+@item
+The new functions @code{mouse-position} and @code{set-mouse-position} give
+access to the current position of the mouse.
+@code{mouse-position} returns a description of the position of the mouse.
+The value looks like @code{(@var{frame} @var{x} . @var{y})}, where @var{x}
+and @var{y} are measured in pixels relative to the top left corner of
+the inside of @var{frame}.
+@code{set-mouse-position} takes three arguments, @var{frame}, @var{x}
+and @var{y}, and warps the mouse cursor to that location on the screen.
+@item
+@code{track-mouse} is a new special form for tracking mouse motion.
+Use it in definitions of mouse clicks that want pay to attention to
+the motion of the mouse, not just where the buttons are pressed and
+released.  Here is how to use it:
+@example
+(track-mouse @var{body}@dots{})
+@end example
+While @var{body} executes, mouse motion generates input events just as mouse
+clicks do.  @var{body} can read them with @code{read-event} or
+@code{read-key-sequence}.
+@code{track-mouse} returns the value of the last form in @var{body}.
+The format of these events is described under ``New Input Event Formats.''
+@item
+@code{x-set-selection} sets a ``selection'' in the X server.
+It takes two arguments: a selection type @var{type}, and the value to
+assign to it, @var{data}.  If @var{data} is @code{nil}, it means to
+clear out the selection.  Otherwise, @var{data} may be a string, a
+symbol, an integer (or a cons of two integers or list of two integers),
+or a cons of two markers pointing to the same buffer.  In the last case,
+the selection is considered to be the text between the markers.  The
+data may also be a vector of valid non-vector selection values.
+Each possible @var{type} has its own selection value, which changes
+independently.  The usual values of @var{type} are @code{PRIMARY} and
+@code{SECONDARY}; these are symbols with upper-case names, in accord
+with X protocol conventions.  The default is @code{PRIMARY}.
+To get the value of the selection, call @code{x-get-selection}.  This
+function accesses selections set up by Emacs and those set up by other X
+clients.  It takes two optional arguments, @var{type} and
+@var{data-type}.  The default for @var{type} is @code{PRIMARY}.
+The @var{data-type} argument specifies the form of data conversion to
+use; meaningful values include @code{TEXT}, @code{STRING},
+@code{TARGETS}, @code{LENGTH}, @code{DELETE}, @code{FILE_NAME},
+@code{CHARACTER_POSITION}, @code{LINE_NUMBER}, @code{COLUMN_NUMBER},
+@code{OWNER_OS}, @code{HOST_NAME}, @code{USER}, @code{CLASS},
+@code{NAME}, @code{ATOM}, and @code{INTEGER}.  (These are symbols with
+upper-case names in accord with X Windows conventions.)
+The default for @var{data-type} is @code{STRING}.
+@item
+The X server has a set of numbered @dfn{cut buffers} which can store text
+or other data being moved between applications.  Use
+@code{x-get-cut-buffer} to get the contents of a cut buffer; specify the
+cut buffer number as argument.  Use @code{x-set-cut-buffer} with
+argument @var{string} to store a new string into the first cut buffer
+(moving the other values down through the series of cut buffers,
+kill-ring-style).
+Cut buffers are considered obsolete, but Emacs supports them for the
+sake of X clients that still use them.
+@item
+You can close the connection with the X server with the function
+@code{x-close-current-connection}.  This takes no arguments.
+Then you can connect to a different X server with
+@code{x-open-connection}.  The first argument, @var{display}, is the
+name of the display to connect to.
+The optional second argument @var{xrm-string} is a string of resource
+names and values, in the same format used in the @file{.Xresources}
+file.  The values you specify override the resource values recorded in
+the X server itself.  Here's an example of what this string might look
+like:
+@example
+"*BorderWidth: 3\n*InternalBorder: 2\n"
+@end example
+@item
+A series of new functions give you information about the X server and
+the screen you are using.
+@table @code
+@item x-display-screens
+The number of screens associated with the current display.
+@item x-server-version
+The version numbers of the X server in use.
+@item x-server-vendor
+The vendor supporting the X server in use.
+@item x-display-pixel-height
+The height of this X screen in pixels.
+@item x-display-mm-height
+The height of this X screen in millimeters.
+@item x-display-pixel-width
+The width of this X screen in pixels.
+@item x-display-mm-width
+The width of this X screen in millimeters.
+@item x-display-backing-store
+The backing store capability of this screen.  Values can be the symbols
+@code{always}, @code{when-mapped}, or @code{not-useful}.
+@item x-display-save-under
+Non-@code{nil} if this X screen supports the SaveUnder feature.
+@item x-display-planes
+The number of planes this display supports.
+@item x-display-visual-class
+The visual class for this X screen.  The value is one of the symbols
+@code{static-gray}, @code{gray-scale}, @code{static-color},
+@code{pseudo-color}, @code{true-color}, and @code{direct-color}.
+@item x-display-color-p
+@code{t} if the X screen in use is a color screen.
+@item x-display-color-cells
+The number of color cells this X screen supports.
+@end table
+There is also a variable @code{x-no-window-manager}, whose value is
+@code{t} if no X window manager is in use.
+@item
+The function @code{x-synchronize} enables or disables an X Windows
+debugging mode: synchronous communication.  It takes one argument,
+non-@code{nil} to enable the mode and @code{nil} to disable.
+In synchronous mode, Emacs waits for a response to each X protocol
+command before doing anything else.  This means that errors are reported
+right away, and you can directly find the erroneous command.
+Synchronous mode is not the default because it is much slower.
+@item
+The function @code{x-get-resource} retrieves a resource value from the X
+Windows defaults database.  Its three arguments are @var{attribute},
+@var{name} and @var{class}.  It searches using a key of the form
+@samp{@var{instance}.@var{attribute}}, with class @samp{Emacs}, where
+@var{instance} is the name under which Emacs was invoked.
+The optional arguments @var{component} and @var{subclass} add to the key
+and the class, respectively.  You must specify both of them or neither.
+If you specify them, the key is
+@samp{@var{instance}.@var{component}.@var{attribute}}, and the class is
+@samp{Emacs.@var{subclass}}.
+@item
+@code{x-display-color-p} returns @code{t} if you are using an X server
+with a color display, and @code{nil} otherwise.
+@c ??? Name being changed from x-defined-color.
+@code{x-color-defined-p} takes as argument a string describing a color; it
+returns @code{t} if the display supports that color.  (If the color is
+@code{"black"} or @code{"white"} then even black-and-white displays
+support it.)
+@item
+@code{x-popup-menu} has been generalized.  It now accepts a keymap as
+the @var{menu} argument.  Then the menu items are the prompt strings of
+individual key bindings, and the item values are the keys which have
+those bindings.
+You can also supply a list of keymaps as the first argument; then each
+keymap makes one menu pane (but keymaps that don't provide any menu
+items don't appear in the menu at all).
+@code{x-popup-menu} also accepts a mouse button event as the
+@var{position} argument.  Then it displays the menu at the location at
+which the event took place.  This is convenient for mouse-invoked
+commands that pop up menus.
+@ignore
+@item
+x-pointer-shape, x-nontext-pointer-shape, x-mode-pointer-shape.
+@end ignore
+@item
+You can use the function @code{x-rebind-key} to change the sequence of
+characters generated by the X server for one of the keyboard keys.
+The first two arguments, @var{keycode} and @var{shift-mask}, should be
+numbers representing the keyboard code and shift mask respectively.
+They specify what key to change.
+The third argument, @var{newstring}, is the new definition of the key.
+It is a sequence of characters that the key should produce as input.
+The shift mask value is a combination of bits according to this table:
+@table @asis
+@item 8
+Control
+@item 4
+Meta
+@item 2
+Shift
+@item 1
+Shift Lock
+@end table
+If you specify @code{nil} for @var{shift-mask}, then the key specified
+by @var{keycode} is redefined for all possible shift combinations.
+For the possible values of @var{keycode} and their meanings, see the
+file @file{/usr/lib/Xkeymap.txt}.  Keep in mind that the codes in that
+file are in octal!
+@ignore @c Presumably this is already fixed
+NOTE: due to an X bug, this function will not take effect unless the
+user has a @file{~/.Xkeymap} file.  (See the documentation for the
+@code{keycomp} program.)  This problem will be fixed in X version 11.
+@end ignore
+The related function @code{x-rebind-keys} redefines a single keyboard
+key, specifying the behavior for each of the 16 shift masks
+independently.  The first argument is @var{keycode}, as in
+@code{x-rebind-key}.  The second argument @var{strings} is a list of 16
+elements, one for each possible shift mask value; each element says how
+to redefine the key @var{keycode} with the corresponding shift mask
+value.  If an element is a string, it is the new definition.  If an
+element is @code{nil}, the definition does not change for that shift
+mask.
+@item
+The function @code{x-parse-geometry} parses a string specifying window
+size and position in the usual X format.  It returns an alist describing
+which parameters were specified, and the values that were given for
+them.
+The elements of the alist look like @code{(@var{parameter} .
+@var{value})}.  The possible @var{parameter} values are @code{left},
+@code{top}, @code{width}, and @code{height}.
+@end itemize
+@section New Window Features
+@itemize @bullet
+@item
+The new function @code{window-at} tells you which window contains a
+given horizontal and vertical position on a specified frame.  Call it
+with three arguments, like this:
+@example
+(window-at @var{x} @var{column} @var{frame})
+@end example
+The function returns the window which contains that cursor position in
+the frame @var{frame}.  If you omit @var{frame}, the selected frame is
+used.
+@item
+The function @code{coordinates-in-window-p} takes two arguments and
+checks whether a particular frame position falls within a particular
+window.
+@example
+(coordinates-in-window-p @var{coordinates} @var{window})
+@end example
+The argument @var{coordinates} is a cons cell of this form:
+@example
+(@var{x} . @var{y})
+@end example
+@noindent
+The two coordinates are measured in characters, and count from the top
+left corner of the screen or frame.
+The value of the function tells you what part of the window the position
+is in.  The possible values are:
+@table @code
+@item (@var{relx} . @var{rely})
+The coordinates are inside @var{window}.  The numbers @var{relx} and
+@var{rely} are equivalent window-relative coordinates, counting from 0
+at the top left corner of the window.
+@item mode-line
+The coordinates are in the mode line of @var{window}.
+@item vertical-split
+The coordinates are in the vertical line between @var{window} and its
+neighbor to the right.
+@item nil
+The coordinates are not in any sense within @var{window}.
+@end table
+You need not specify a frame when you call
+@code{coordinates-in-window-p}, because it assumes you mean the frame
+which window @var{window} is on.
+@item
+The function @code{minibuffer-window} now accepts a frame as argument
+and returns the minibuffer window used for that frame.  If you don't
+specify a frame, the currently selected frame is used.  The minibuffer
+window may be on the frame in question, but if that frame has no
+minibuffer of its own, it uses the minibuffer window of some other
+frame, and @code{minibuffer-window} returns that window.
+@item
+Use @code{window-live-p} to test whether a window is still alive (that
+is, not deleted).
+@item
+Use @code{window-minibuffer-p} to determine whether a given window is a
+minibuffer or not.  It no longer works to do this by comparing the
+window with the result of @code{(minibuffer-window)}, because there can
+be more than one minibuffer window at a time (if you have multiple
+frames).
+@item
+If you set the variable @code{pop-up-frames} non-@code{nil}, then the
+functions to show something ``in another window'' actually create a new
+frame for the new window.  Thus, you will tend to have a frame for each
+window, and you can easily have a frame for each buffer.
+The value of the variable @code{pop-up-frame-function} controls how new
+frames are made.  The value should be a function which takes no
+arguments and returns a frame.  The default value is a function which
+creates a frame using parameters from @code{pop-up-frame-alist}.
+@item
+@code{display-buffer} is the basic primitive for finding a way to show a
+buffer on the screen.  You can customize its behavior by storing a
+function in the variable @code{display-buffer-function}.  If this
+variable is non-@code{nil}, then @code{display-buffer} calls it to do
+the work.  Your function should accept two arguments, as follows:
+@table @var
+@item buffer
+The buffer to be displayed.
+@item flag
+A flag which, if non-@code{nil}, means you should find another window to
+display @var{buffer} in, even if it is already visible in the selected
+window.
+@end table
+The function you supply will be used by commands such as
+@code{switch-to-buffer-other-window} and @code{find-file-other-window}
+as well as for your own calls to @code{display-buffer}.
+@item
+@code{delete-window} now gives all of the deleted window's screen space
+to a single neighboring window.  Likewise, @code{enlarge-window} takes
+space from only one neighboring window until that window disappears;
+only then does it take from another window.
+@item
+@code{next-window} and @code{previous-window} accept another argument,
+@var{all-frames}.
+These functions now take three optional arguments: @var{window},
+@var{minibuf} and @var{all-frames}.  @var{window} is the window to start
+from (@code{nil} means use the selected window).  @var{minibuf} says
+whether to include the minibuffer in the windows to cycle through:
+@code{t} means yes, @code{nil} means yes if it is active, and anything
+else means no.
+Normally, these functions cycle through all the windows in the
+selected frame, plus the minibuffer used by the selected frame even if
+it lies in some other frame.
+If @var{all-frames} is @code{t}, then these functions cycle through
+all the windows in all the frames that currently exist.  If
+@var{all-frames} is neither @code{t} nor @code{nil}, then they limit
+themselves strictly to the windows in the selected frame, excluding the
+minibuffer in use if it lies in some other frame.
+@item
+The functions @code{get-lru-window} and @code{get-largest-window} now
+take an optional argument @var{all-frames}.  If it is non-@code{nil},
+the functions consider all windows on all frames.  Otherwise, they
+consider just the windows on the selected frame.
+Likewise, @code{get-buffer-window} takes an optional second argument
+@var{all-frames}.
+@item
+The variable @code{other-window-scroll-buffer} specifies which buffer
+@code{scroll-other-window} should scroll.
+@item
+You can now mark a window as ``dedicated'' to its buffer.
+Then Emacs will not try to use that window for any other buffer
+unless you explicitly request it.
+Use the new function @code{set-window-dedicated-p} to set the dedication
+flag of a window @var{window} to the value @var{flag}.  If @var{flag} is
+@code{t}, this makes the window dedicated.  If @var{flag} is
+@code{nil}, this makes the window non-dedicated.
+Use @code{window-dedicated-p} to examine the dedication flag of a
+specified window.
+@item
+The new function @code{walk-windows} cycles through all visible
+windows, calling @code{proc} once for each window with the window as
+its sole argument.
+The optional second argument @var{minibuf} says whether to include minibuffer
+windows.  A value of @code{t} means count the minibuffer window even if
+not active.  A value of @code{nil} means count it only if active.  Any
+other value means not to count the minibuffer even if it is active.
+If the optional third argument @var{all-frames} is @code{t}, that means
+include all windows in all frames.  If @var{all-frames} is @code{nil},
+it means to cycle within the selected frame, but include the minibuffer
+window (if @var{minibuf} says so) that that frame uses, even if it is on
+another frame.  If @var{all-frames} is neither @code{nil} nor @code{t},
+@code{walk-windows} sticks strictly to the selected frame.
+@item
+The function @code{window-end} is a counterpart to @code{window-start}:
+it returns the buffer position of the end of the display in a given
+window (or the selected window).
+@item
+The function @code{window-configuration-p} returns non-@code{nil} when
+given an object that is a window configuration (such as is returned by
+@code{current-window-configuration}).
+@end itemize
+@section Display Features
+@itemize @bullet
+@item
+@code{baud-rate} is now a variable rather than a function.  This is so
+you can set it to reflect the effective speed of your terminal, when the
+system doesn't accurately know the speed.
+@item
+You can now remove any echo area message and make the minibuffer
+visible.  To do this, call @code{message} with @code{nil} as the only
+argument.  This clears any existing message, and lets the current
+minibuffer contents show through.  Previously, there was no reliable way
+to make sure that the minibuffer contents were visible.
+@item
+The variable @code{temp-buffer-show-hook} has been renamed
+@code{temp-buffer-show-function}, because its value is a single function
+(of one argument), not a normal hook.
+@item
+The new function @code{force-mode-line-update} causes redisplay
+of the current buffer's mode line.
+@end itemize
+@section Display Tables
+@cindex display table
+You can use the @dfn{display table} feature to control how all 256
+possible character codes display on the screen.  This is useful for
+displaying European languages that have letters not in the ASCII
+character set.
+The display table maps each character code into a sequence of
+@dfn{glyphs}, each glyph being an image that takes up one character
+position on the screen.  You can also define how to display each glyph
+on your terminal, using the @dfn{glyph table}.
+@subsection Display Tables Proper
+Use @code{make-display-table} to create a display table.  The table
+initially has @code{nil} in all elements.
+A display table is actually an array of 261 elements.  The first 256
+elements of a display table control how to display each possible text
+character.  The value should be @code{nil} or a vector (which is a
+sequence of glyphs; see below).  @code{nil} as an element means to
+display that character following the usual display conventions.
+The remaining five elements of a display table serve special purposes
+(@code{nil} means use the default stated below):
+@table @asis
+@item 256
+The glyph for the end of a truncated screen line (the default for this
+is @samp{\}).
+@item 257
+The glyph for the end of a continued line (the default is @samp{$}).
+@item 258
+The glyph for the indicating an octal character code (the default is
+@samp{\}).
+@item 259
+The glyph for indicating a control characters (the default is @samp{^}).
+@item 260
+The vector of glyphs for indicating the presence of invisible lines (the
+default is @samp{...}).
+@end table
+Each buffer typically has its own display table.  The display table for
+the current buffer is stored in @code{buffer-display-table}.  (This
+variable automatically becomes local if you set it.)  If this variable
+is @code{nil}, the value of @code{standard-display-table} is used in
+that buffer.
+Each window can have its own display table, which overrides the display
+table of the buffer it is showing.
+If neither the selected window nor the current buffer has a display
+table, and if @code{standard-display-table} is @code{nil}, then Emacs
+uses the usual display conventions:
+@itemize @bullet
+@item
+Character codes 32 through 127 map to glyph codes 32 through 127.
+@item
+Codes 0 through 31 map to sequences of two glyphs, where the first glyph
+is the ASCII code for @samp{^}.
+@item
+Character codes 128 through 255 map to sequences of four glyphs, where
+the first glyph is the ASCII code for @samp{\}, and the others represent
+digits.
+@end itemize
+The usual display conventions are also used for any character whose
+entry in the active display table is @code{nil}.  This means that when
+you set up a display table, you need not specify explicitly what to do
+with each character, only the characters for which you want unusual
+behavior.
+@subsection Glyphs
+@cindex glyph
+A glyph stands for an image that takes up a single character position on
+the screen.  A glyph is represented in Lisp as an integer.
+@cindex glyph table
+The meaning of each integer, as a glyph, is defined by the glyph table,
+which is the value of the variable @code{glyph-table}.  It should be a
+vector; the @var{g}th element defines glyph code @var{g}.  The possible
+definitions of a glyph code are:
+@table @var
+@item integer
+Define this glyph code as an alias for code @var{integer}.
+This is used with X Windows to specify a face code.
+@item string
+Send the characters in @var{string} to the terminal to output this
+glyph.  This alternative is available only for character terminals, not
+with X.
+@item @code{nil}
+This glyph is simple.  On an ordinary terminal, the glyph code mod 256
+is the character to output.  With X, the glyph code mod 256 is character
+to output, and the glyph code divided by 256 specifies the @dfn{face
+code} to use while outputting it.
+@end table
+Any glyph code beyond the length of the glyph table is automatically simple.
+If @code{glyph-table} is @code{nil}, then all possible glyph codes are
+simple.
+A @dfn{face} is a named combination of a font and a pair of colors
+(foreground and background).  A glyph code can specify a face id number
+to use for displaying that glyph.
+@subsection ISO Latin 1
+If you have a terminal that can handle the entire ISO Latin 1 character
+set, you can arrange to use that character set as follows:
+@example
+(standard-display-european 1)
+@end example
+If you are editing buffers written in the ISO Latin 1 character set and
+your terminal doesn't handle anything but ASCII, you can load the file
+@code{iso-ascii} to set up a display table which makes the other ISO
+characters display as sequences of ASCII characters.  For example, the
+character ``o with umlaut'' displays as @samp{@{"o@}}.
+Some European countries have terminals that don't support ISO Latin 1
+but do support the special characters for that country's language.  You
+can define a display table to work one language using such terminals.
+For an example, see @file{lisp/iso-swed.el}, which handles certain
+Swedish terminals.
+You can load the appropriate display table for your terminal
+automatically by writing a terminal-specific Lisp file for the terminal
+type.
+@section Overlays
+@cindex overlays
+You can use @dfn{overlays} to alter the appearance of a buffer's text on
+the screen.  An overlay is an object which belongs to a particular
+buffer, and has a specified beginning and end.  It also has properties
+which you can examine and set; these affect the display of the text
+within the overlay.
+@subsection Overlay Properties
+Overlay properties are like text properties in some respects, but the
+differences are more important than the similarities.  Text properties
+are considered a part of the text; overlays are specifically considered
+not to be part of the text.  Thus, copying text between various buffers
+and strings preserves text properties, but does not try to preserve
+overlays.  Changing a buffer's text properties marks the buffer as
+modified, while moving an overlay or changing its properties does not.
+@table @code
+@item face
+@kindex face
+This property specifies a face for displaying the text within the overlay.
+@item priority
+@kindex priority
+This property's value (which should be a nonnegative number) determines
+the priority of the overlay.  The priority matters when two or more
+overlays cover the same character and both specify a face for display;
+the one whose @code{priority} value is larger takes priority over the
+other, and its face attributes override the face attributes of the lower
+priority overlay.
+Currently, all overlays take priority over text properties.  Please
+avoid using negative priority values, as we have not yet decided just
+what they should mean.
+@item window
+@kindex window
+If the @code{window} property is non-@code{nil}, then the overlay
+applies only on that window.
+@end table
+@subsection Overlay Functions
+Use the functions @code{overlay-get} and @code{overlay-put}
+to access and set the properties of an overlay.
+They take arguments like @code{get} and @code{put}, except
+that the first argument is an overlay rather than a symbol.
+To create an overlay, call @code{(make-overlay @var{start} @var{end})}.
+You can specify the buffer as the third argument if you wish.
+To delete one, use @code{delete-overlay}.
+Use @code{overlay-start}, @code{overlay-end} and @code{overlay-buffer}
+to examine the location and range of an overlay.  Use @code{move-overlay}
+to change them; its arguments are @var{overlay}, @var{start}, @var{end}
+and (optionally) the buffer.
+There are two functions to search for overlays: @code{overlays-at} and
+@code{next-overlay-change}.  @code{overlays-at} returns a list of all
+the overlays containing a particular position.
+@code{(next-overlay-change @var{pos})} returns the position of the next
+overlay beginning or end following @var{pos}.
+@section Faces
+A @dfn{face} is a named collection of graphical attributes: font,
+foreground color, background color and optional underlining.  Faces
+control the display of text on the screen.
+Each face has its own @dfn{face id number} which distinguishes faces at
+low levels within Emacs.  However, for most purposes, you can refer to
+faces in Lisp programs by their names.
+Each face name is meaningful for all frames, and by default it has the
+same meaning in all frames.  But you can arrange to give a particular
+face name a special meaning in one frame if you wish.
+@subsection Choosing a Face for Display
+Here are all the ways to specify which face to use for display of text:
+@itemize @bullet
+@item
+With defaults.  Each frame has a @dfn{default face}, whose id number is
+zero, which is used for all text that doesn't somehow specify another
+face.
+@item
+With text properties.  A character may have a @code{face} property; if so,
+it's displayed with that face.  If the character has a @code{mouse-face}
+property, that is used instead of the @code{face} property when the mouse
+is ``near enough'' to the character.
+@item
+With overlays.  An overlay may have @code{face} and @code{mouse-face}
+properties too; they apply to all the text covered by the overlay.
+@item
+With special glyphs.  Each glyph can specify a particular face id
+number.
+@end itemize
+If these various sources together specify more than one face for a
+particular character, Emacs merges the attributes of the various faces
+specified.  The attributes of the faces of special glyphs come first;
+then come attributes of faces from overlays, followed by those from text
+properties, and last the default face.
+When multiple overlays cover one character, an overlay with higher
+priority overrides those with lower priority.
+If an attribute such as the font or a color is not specified in any of
+the above ways, the frame's own font or color is used.
+@xref{Face Functions,, Face Functions, elisp, The Emacs Lisp Reference
+Manual}, for functions to create and change faces.
+@section New Input Event Formats
+Mouse clicks, mouse movements and function keys no longer appear in the
+input stream as characters; instead, other kinds of Lisp objects
+represent them as input.
+@itemize @bullet
+@item
+An ordinary input character event consists of a @dfn{basic code} between
+0 and 255, plus any or all of these @dfn{modifier bits}:
+@table @asis
+@item meta
+The 2**23 bit in the character code indicates a character
+typed with the meta key held down.
+@item control
+The 2**22 bit in the character code indicates a non-@sc{ASCII}
+control character.
+@sc{ASCII} control characters such as @kbd{C-a} have special basic
+codes of their own, so Emacs needs no special bit to indicate them.
+Thus, the code for @kbd{C-a} is just 1.
+But if you type a control combination not in @sc{ASCII}, such as
+@kbd{%} with the control key, the numeric value you get is the code
+for @kbd{%} plus 2**22 (assuming the terminal supports non-@sc{ASCII}
+control characters).
+@item shift
+The 2**21 bit in the character code indicates an @sc{ASCII} control
+character typed with the shift key held down.
+For letters, the basic code indicates upper versus lower case; for
+digits and punctuation, the shift key selects an entirely different
+character with a different basic code.  In order to keep within
+the @sc{ASCII} character set whenever possible, Emacs avoids using
+the 2**21 bit for those characters.
+However, @sc{ASCII} provides no way to distinguish @kbd{C-A} from
+@kbd{C-a}, so Emacs uses the 2**21 bit in @kbd{C-A} and not in
+@kbd{C-a}.
+@item hyper
+The 2**20 bit in the character code indicates a character
+typed with the hyper key held down.
+@item super
+The 2**19 bit in the character code indicates a character
+typed with the super key held down.
+@item alt
+The 2**18 bit in the character code indicates a character typed with
+the alt key held down.  (On some terminals, the key labeled @key{ALT}
+is actually the meta key.)
+@end table
+In the future, Emacs may support a larger range of basic codes.  We may
+also move the modifier bits to larger bit numbers.  Therefore, you
+should avoid mentioning specific bit numbers in your program.  Instead,
+the way to test the modifier bits of a character is with the function
+@code{event-modifiers} (see below).
+@item
+Function keys are represented as symbols.  The symbol's name is
+the function key's label.  For example, pressing a key labeled @key{F1}
+places the symbol @code{f1} in the input stream.
+There are a few exceptions to the symbol naming convention:
+@table @asis
+@item @code{kp-add}, @code{kp-decimal}, @code{kp-divide}, @dots{}
+Keypad keys (to the right of the regular keyboard).
+@item @code{kp-0}, @code{kp-1}, @dots{}
+Keypad keys with digits.
+@item @code{kp-f1}, @code{kp-f2}, @code{kp-f3}, @code{kp-f4}
+Keypad PF keys.
+@item @code{left}, @code{up}, @code{right}, @code{down}
+Cursor arrow keys
+@end table
+You can use the modifier keys @key{CTRL}, @key{META}, @key{HYPER},
+@key{SUPER}, @key{ALT} and @key{SHIFT} with function keys.  The way
+to represent them is with prefixes in the symbol name:
+@table @samp
+@item A-
+The alt modifier.
+@item C-
+The control modifier.
+@item H-
+The hyper modifier.
+@item M-
+The meta modifier.
+@item s-
+The super modifier.
+@item S-
+The shift modifier.
+@end table
+Thus, the symbol for the key @key{F3} with @key{META} held down is
+@kbd{M-@key{F3}}.  When you use more than one prefix, we recommend you
+write them in alphabetical order (though the order does not matter in
+arguments to the key-binding lookup and modification functions).
+@item
+Mouse events are represented as lists.
+If you press a mouse button and release it at the same location, this
+generates a ``click'' event.  Mouse click events have this form:
+@example
+(@var{button-symbol}
+(@var{window} (@var{column} . @var{row})
+@var{buffer-pos} @var{timestamp}))
+@end example
+Here is what the elements normally mean:
+@table @var
+@item button-symbol
+indicates which mouse button was used.  It is one of the symbols
+@code{mouse-1}, @code{mouse-2}, @dots{}, where the buttons are normally
+numbered left to right.
+You can also use prefixes @samp{A-}, @samp{C-}, @samp{H-}, @samp{M-},
+@samp{S-} and @samp{s-} for modifiers alt, control, hyper, meta, shift
+and super, just as you would with function keys.
+@item window
+is the window in which the click occurred.
+@item column
+@itemx row
+are the column and row of the click, relative to the top left corner of
+@var{window}, which is @code{(0 . 0)}.
+@item buffer-pos
+is the buffer position of the character clicked on.
+@item timestamp
+is the time at which the event occurred, in milliseconds.  (Since this
+value wraps around the entire range of Emacs Lisp integers in about five
+hours, it is useful only for relating the times of nearby events.)
+@end table
+The meanings of @var{buffer-pos}, @var{row} and @var{column} are
+somewhat different when the event location is in a special part of the
+screen, such as the mode line or a scroll bar.
+If the position is in the window's scroll bar, then @var{buffer-pos} is
+the symbol @code{vertical-scroll-bar}, and the pair @code{(@var{column}
+. @var{row})} is replaced with a pair @code{(@var{portion}
+. @var{whole})}, where @var{portion} is the distance of the click from
+the top or left end of the scroll bar, and @var{whole} is the length of
+the entire scroll bar.
+If the position is on a mode line or the vertical line separating
+@var{window} from its neighbor to the right, then @var{buffer-pos} is
+the symbol @code{mode-line} or @code{vertical-line}.  In this case
+@var{row} and @var{column} do not have meaningful data.
+@item
+Releasing a mouse button above a different character position
+generates a ``drag'' event, which looks like this:
+@example
+(@var{button-symbol}
+(@var{window1} (@var{column1} . @var{row1})
+@var{buffer-pos1} @var{timestamp1})
+(@var{window2} (@var{column2} . @var{row2})
+@var{buffer-pos2} @var{timestamp2}))
+@end example
+The name of @var{button-symbol} contains the prefix @samp{drag-}.  The
+second and third elements of the event give the starting and ending
+position of the drag.
+The @samp{drag-} prefix follows the modifier key prefixes such as
+@samp{C-} and @samp{M-}.
+If @code{read-key-sequence} receives a drag event which has no key
+binding, and the corresponding click event does have a binding, it
+changes the drag event into a click event at the drag's starting
+position.  This means that you don't have to distinguish between click
+and drag events unless you want to.
+@item
+Click and drag events happen when you release a mouse button.  Another
+kind of event happens when you press a button.  It looks just like a
+click event, except that the name of @var{button-symbol} contains the
+prefix @samp{down-}.  The @samp{down-} prefix follows the modifier key
+prefixes such as @samp{C-} and @samp{M-}.
+The function @code{read-key-sequence}, and the Emacs command loop,
+ignore any down events that don't have command bindings.  This means
+that you need not worry about defining down events unless you want them
+to do something.  The usual reason to define a down event is so that you
+can track mouse motion until the button is released.
+@item
+For example, if the user presses and releases the left mouse button over
+the same location, Emacs generates a sequence of events like this:
+@smallexample
+(down-mouse-1 (#<window 18 on NEWS> 2613 (0 . 38) -864320))
+(mouse-1      (#<window 18 on NEWS> 2613 (0 . 38) -864180))
+@end smallexample
+Or, while holding the control key down, the user might hold down the
+second mouse button, and drag the mouse from one line to the next.
+That produces two events, as shown here:
+@smallexample
+(C-down-mouse-2 (#<window 18 on NEWS> 3440 (0 . 27) -731219))
+(C-drag-mouse-2 (#<window 18 on NEWS> 3440 (0 . 27) -731219)
+(#<window 18 on NEWS> 3510 (0 . 28) -729648))
+@end smallexample
+Or, while holding down the meta and shift keys, the user might press
+the second mouse button on the window's mode line, and then drag the
+mouse into another window.  That produces an event like this:
+@smallexample
+(M-S-down-mouse-2 (#<window 18 on NEWS> mode-line (33 . 31) -457844))
+(M-S-drag-mouse-2 (#<window 18 on NEWS> mode-line (33 . 31) -457844)
+(#<window 20 on carlton-sanskrit.tex> 161 (33 . 3)
+-453816))
+@end smallexample
+@item
+A key sequence that starts with a mouse click is read using the keymaps
+of the buffer in the window clicked on, not the current buffer.
+This does not imply that clicking in a window selects that window or its
+buffer.  The execution of the command begins with no change in the
+selected window or current buffer.  However, the command can switch
+windows or buffers if programmed to do so.
+@item
+Mouse motion events are represented by lists.  During the execution of
+the body of a @code{track-mouse} form, moving the mouse generates events
+that look like this:
+@example
+(mouse-movement (@var{window} (@var{column} . @var{row})
+@var{buffer-pos} @var{timestamp}))
+@end example
+The second element of the list describes the current position of the
+mouse, just as in a mouse click event.
+Outside of @code{track-mouse} forms, Emacs does not generate events for
+mere motion of the mouse, and these events do not appear.
+@item
+Focus shifts between frames are represented by lists.
+When the mouse shifts temporary input focus from one frame to another,
+Emacs generates an event like this:
+@example
+(switch-frame @var{new-frame})
+@end example
+@noindent
+where @var{new-frame} is the frame switched to.
+In X windows, most window managers are set up so that just moving the
+mouse into a window is enough to set the focus there.  As far as the
+user is concerned, Emacs behaves consistently with this.  However, there is
+no need for the Lisp program to know about the focus change until some
+other kind of input arrives.  So Emacs generates the focus event only
+when the user actually types a keyboard key or presses a mouse button in
+the new frame; just moving the mouse between frames does not generate a
+focus event.
+The global key map usually binds this event to the
+@code{internal-select-frame} function, so that characters typed at a
+frame apply to that frame's selected window.
+If the user switches frames in the middle of a key sequence, then Emacs
+delays the @code{switch-frame} event until the key sequence is over.
+For example, suppose @kbd{C-c C-a} is a key sequence in the current
+buffer's keymaps.  If the user types @kbd{C-c}, moves the mouse to
+another frame, and then types @kbd{C-a}, @code{read-key-sequence}
+returns the sequence @code{"\C-c\C-a"}, and the next call to
+@code{read-event} or @code{read-key-sequence} will return the
+@code{switch-frame} event.
+@end itemize
+@section Working with Input Events
+@itemize @bullet
+@item
+Functions which work with key sequences now handle non-character
+events.  Functions like @code{define-key}, @code{global-set-key}, and
+@code{local-set-key} used to accept strings representing key sequences;
+now, since events may be arbitrary lisp objects, they also accept
+vectors.  The function @code{read-key-sequence} may return a string or a
+vector, depending on whether or not the sequence read contains only
+characters.
+List events may be represented by the symbols at their head; to bind
+clicks of the left mouse button, you need only present the symbol
+@code{mouse-1}, not an entire mouse click event.  If you do put an event
+which is a list in a key sequence, only the event's head symbol is used
+in key lookups.
+For example, to globally bind the left mouse button to the function
+@code{mouse-set-point}, you could evaluate this:
+@example
+(global-set-key [mouse-1] 'mouse-set-point)
+@end example
+To bind the sequence @kbd{C-c @key{F1}} to the command @code{tex-view}
+in @code{tex-mode-map}, you could evaluate this:
+@example
+(define-key tex-mode-map [?\C-c f1] 'tex-view)
+@end example
+To find the binding for the function key labeled @key{NEXT} in
+@code{minibuffer-local-map}, you could evaluate this:
+@example
+(lookup-key minibuffer-local-map [next])
+@result{} next-history-element
+@end example
+If you call the function @code{read-key-sequence} and then press
+@kbd{C-x C-@key{F5}}, here is how it behaves:
+@example
+(read-key-sequence "Press `C-x C-F5': ")
+@result{} [24 C-f5]
+@end example
+Note that @samp{24} is the character @kbd{C-x}.
+@item
+The documentation functions (@code{single-key-description},
+@code{key-description}, etc.) now handle the new event types.  Wherever
+a string of keyboard input characters was acceptable in previous
+versions of Emacs, a vector of events should now work.
+@item
+Special parts of a window can have their own bindings for mouse events.
+When mouse events occur in special parts of a window, such as a mode
+line or a scroll bar, the event itself shows nothing special---only the
+symbol that would normally represent that mouse button and modifier
+keys.  The information about the screen region is kept in other parts
+of the event list.  But @code{read-key-sequence} translates this
+information into imaginary prefix keys, all of which are symbols:
+@code{mode-line}, @code{vertical-line}, and
+@code{vertical-scroll-bar}.
+For example, if you call @code{read-key-sequence} and then click the
+mouse on the window's mode line, this is what happens:
+@smallexample
+(read-key-sequence "Click on the mode line: ")
+@result{} [mode-line (mouse-1 (#<window 6 on NEWS> mode-line
+(40 . 63) 5959987))]
+@end smallexample
+You can define meanings for mouse clicks in special window regions by
+defining key sequences using these imaginary prefix keys.  For example,
+here is how to bind the third mouse button on a window's mode line
+delete the window:
+@example
+(global-set-key [mode-line mouse-3] 'mouse-delete-window)
+@end example
+Here's how to bind the middle button (modified by @key{META}) on the
+vertical line at the right of a window to scroll the window to the
+left.
+@example
+(global-set-key [vertical-line M-mouse-2] 'scroll-left)
+@end example
+@item
+Decomposing an event symbol.
+Each symbol used to identify a function key or mouse button has a
+property named @code{event-symbol-elements}, which is a list containing
+an unmodified version of the symbol, followed by modifiers the symbol
+name contains.  The modifiers are symbols; they include @code{shift},
+@code{control}, and @code{meta}.  In addition, a mouse event symbol has
+one of @code{click}, @code{drag}, and @code{down}.  For example:
+@example
+(get 'f5 'event-symbol-elements)
+@result{} (f5)
+(get 'C-f5 'event-symbol-elements)
+@result{} (f5 control)
+(get 'M-S-f5 'event-symbol-elements)
+@result{} (f5 meta shift)
+(get 'mouse-1 'event-symbol-elements)
+@result{} (mouse-1 click)
+(get 'down-mouse-1 'event-symbol-elements)
+@result{} (mouse-1 down)
+@end example
+Note that the @code{event-symbol-elements} property for a mouse click
+explicitly contains @code{click}, but the event symbol name itself does
+not contain @samp{click}.
+@item
+Use @code{read-event} to read input if you want to accept any kind of
+event.  The old function @code{read-char} now discards events other than
+keyboard characters.
+@item
+@code{last-command-char} and @code{last-input-char} can now hold any
+kind of event.
+@item
+The new variable @code{unread-command-events} is much like
+@code{unread-command-char}.  Its value is a list of events of any type,
+to be processed as command input in order of appearance in the list.
+@item
+The function @code{this-command-keys} may return a string or a vector,
+depending on whether or not the sequence read contains only characters.
+You may need to upgrade code which uses this function.
+The function @code{recent-keys} now returns a vector of events.
+You may need to upgrade code which uses this function.
+@item
+A keyboard macro's definition can now be either a string or a vector.
+All that really matters is what elements it has.  If the elements are
+all characters, then the macro can be a string; otherwise, it has to be
+a vector.
+@item
+The variable @code{last-event-frame} records which frame the last input
+event was directed to.  Usually this is the frame that was selected when
+the event was generated, but if that frame has redirected input focus to
+another frame, @code{last-event-frame} is the frame to which the event
+was redirected.
+@item
+The interactive specification now allows a new code letter @samp{e} to
+simplify commands bound to events which are lists.  This code supplies
+as an argument the complete event object.
+You can use @samp{e} more than once in a single command's interactive
+specification.  If the key sequence which invoked the command has
+@var{n} events with parameters, the @var{n}th @samp{e} provides the
+@var{n}th parameterized event.  Events which are not lists, such as
+function keys and ASCII keystrokes, do not count where @samp{e} is
+concerned.
+@item
+You can extract the starting and ending position values from a mouse
+button or motion event using the two functions @code{event-start} and
+@code{event-end}.  These two functions return different values for drag
+and motion events; for click and button-down events, they both return
+the position of the event.
+@item
+The position, a returned by @code{event-start} and @code{event-end}, is
+a list of this form:
+@example
+(@var{window} @var{buffer-position} (@var{col} . @var{row}) @var{timestamp})
+@end example
+You can extract parts of this list with the functions
+@code{posn-window}, @code{posn-point}, @code{posn-col-row}, and
+@code{posn-timestamp}.
+@item
+The function @code{scroll-bar-scale} is useful for computing where to
+scroll to in response to a mouse button event from a scroll bar.  It
+takes two arguments, @var{ratio} and @var{total}, and in effect
+multiplies them.  We say ``in effect'' because @var{ratio} is not a
+number; rather a pair @code{(@var{num} . @var{denom})}.
+Here's the usual way to use @code{scroll-bar-scale}:
+@example
+(scroll-bar-scale (posn-col-row (event-start event))
+(buffer-size))
+@end example
+@end itemize
+@section Putting Keyboard Events in Strings
+In most of the places where strings are used, we conceptualize the
+string as containing text characters---the same kind of characters found
+in buffers or files.  Occasionally Lisp programs use strings which
+conceptually contain keyboard characters; for example, they may be key
+sequences or keyboard macro definitions.  There are special rules for
+how to put keyboard characters into a string, because they are not
+limited to the range of 0 to 255 as text characters are.
+A keyboard character typed using the @key{META} key is called a
+@dfn{meta character}.  The numeric code for such an event includes the
+2**23 bit; it does not even come close to fitting in a string.  However,
+earlier Emacs versions used a different representation for these
+characters, which gave them codes in the range of 128 to 255.  That did
+fit in a string, and many Lisp programs contain string constants that
+use @samp{\M-} to express meta characters, especially as the argument to
+@code{define-key} and similar functions.
+We provide backward compatibility to run those programs with special
+rules for how to put a keyboard character event in a string.  Here are
+the rules:
+@itemize @bullet
+@item
+If the keyboard event value is in the range of 0 to 127, it can go in the
+string unchanged.
+@item
+The meta variants of those events, with codes in the range of 2**23 to
+2**23+127, can also go in the string, but you must change their numeric
+values.  You must set the 2**7 bit instead of the 2**23 bit, resulting
+in a value between 128 and 255.
+@item
+Other keyboard character events cannot fit in a string.  This includes
+keyboard events in the range of 128 to 255.
+@end itemize
+Functions such as @code{read-key-sequence} that can construct strings
+containing events follow these rules.
+When you use the read syntax @samp{\M-} in a string, it produces a
+code in the range of 128 to 255---the same code that you get if you
+modify the corresponding keyboard event to put it in the string.  Thus,
+meta events in strings work consistently regardless of how they get into
+the strings.
+New programs can avoid dealing with these rules by using vectors
+instead of strings for key sequences when there is any possibility that
+these issues might arise.
+The reason we changed the representation of meta characters as
+keyboard events is to make room for basic character codes beyond 127,
+and support meta variants of such larger character codes.
+@section Menus
+You can now define menus conveniently as keymaps.  Menus are normally
+used with the mouse, but they can work with the keyboard also.
+@subsection Defining Menus
+A keymap is suitable for menu use if it has an @dfn{overall prompt
+string}, which is a string that appears as an element of the keymap.  It
+should describes the purpose of the menu.  The easiest way to construct
+a keymap with a prompt string is to specify the string as an argument
+when you run @code{make-keymap} or @code{make-sparse-keymap}.
+The individual bindings in the menu keymap should also have prompt
+strings; these strings are the items in the menu.  A binding with a
+prompt string looks like this:
+@example
+(@var{char} @var{string} . @var{real-binding})
+@end example
+As far as @code{define-key} is concerned, the string is part of the
+character's binding---the binding looks like this:
+@example
+(@var{string} . @var{real-binding}).
+@end example
+However, only @var{real-binding} is used for executing the key.
+You can also supply a second string, called the help string, as follows:
+@example
+(@var{char} @var{string} @var{help-string} . @var{real-binding})
+@end example
+Currently Emacs does not actually use @var{help-string}; it knows only
+how to ignore @var{help-string} in order to extract @var{real-binding}.
+In the future we hope to make @var{help-string} serve as longer
+documentation for the menu item, available on request.
+The prompt string for a binding should be short---one or two words.  Its
+meaning should describe the command it corresponds to.
+If @var{real-binding} is @code{nil}, then @var{string} appears in the
+menu but cannot be selected.
+If @var{real-binding} is a symbol, and has a non-@code{nil}
+@code{menu-enable} property, that property is an expression which
+controls whether the menu item is enabled.  Every time the keymap is
+used to display a menu, Emacs evaluates the expression, and it enables
+the menu item only if the expression's value is non-@code{nil}.  When a
+menu item is disabled, it is displayed in a ``fuzzy'' fashion, and
+cannot be selected with the mouse.
+@subsection Menus and the Mouse
+The way to make a menu keymap produce a menu is to make it the
+definition of a prefix key.
+When the prefix key ends with a mouse event, Emacs handles the menu
+keymap by popping up a visible menu that you can select from with the
+mouse.  When you click on a menu item, the event generated is whatever
+character or symbol has the binding which brought about that menu item.
+A single keymap can appear as multiple panes, if you explicitly
+arrange for this.  The way to do this is to make a keymap for each
+pane, then create a binding for each of those maps in the main keymap
+of the menu.  Give each of these bindings a prompt string that starts
+with @samp{@@}.  The rest of the prompt string becomes the name of the
+pane.  See the file @file{lisp/mouse.el} for an example of this.  Any
+ordinary bindings with prompt strings are grouped into one pane, which
+appears along with the other panes explicitly created for the
+submaps.
+You can also get multiple panes from separate keymaps.  The full
+definition of a prefix key always comes from merging the definitions
+supplied by the various active keymaps (minor modes, local, and
+global).  When more than one of these keymaps is a menu, each of them
+makes a separate pane or panes.
+@subsection Menus and the Keyboard
+When a prefix key ending with a keyboard event (a character or function
+key) has a definition that is a menu keymap, you can use the keyboard
+to choose a menu item.
+Emacs displays the menu alternatives in the echo area.  If they don't
+all fit at once, type @key{SPC} to see the next line of alternatives.
+If you keep typing @key{SPC}, you eventually get to the end of the menu
+and then cycle around to the beginning again.
+When you have found the alternative you want, type the corresponding
+character---the one whose binding is that alternative.
+In a menu intended for keyboard use, each menu item must clearly
+indicate what character to type.  The best convention to use is to make
+the character the first letter of the menu item prompt string.  That is
+something users will understand without being told.
+@subsection The Menu Bar
+Under X Windows, each frame can have a @dfn{menu bar}---a permanently
+displayed menu stretching horizontally across the top of the frame.  The
+items of the menu bar are the subcommands of the fake ``function key''
+@code{menu-bar}, as defined by all the active keymaps.
+To add an item to the menu bar, invent a fake ``function key'' of your
+own (let's call it @var{key}), and make a binding for the key sequence
+@code{[menu-bar @var{key}]}.  Most often, the binding is a menu keymap,
+so that pressing a button on the menu bar item leads to another menu.
+In order for a frame to display a menu bar, its @code{menu-bar-lines}
+property must be greater than zero.  Emacs uses just one line for the
+menu bar itself; if you specify more than one line, the other lines
+serve to separate the menu bar from the windows in the frame.  We
+recommend you try one or two as the @code{menu-bar-lines} value.
+@section Keymaps
+@itemize @bullet
+@item
+The representation of keymaps has changed to support the new event
+types.  All keymaps now have the form @code{(keymap @var{element}
+@var{element} @dots{})}.  Each @var{element} takes one of the following
+forms:
+@table @asis
+@item @var{prompt-string}
+A string as an element of the keymap marks the keymap as a menu, and
+serves as the overall prompt string for it.
+@item @code{(@var{key} . @var{binding})}
+A cons cell binds @var{key} to @var{definition}.  Here @var{key} may be
+any sort of event head---a character, a function key symbol, or a mouse
+button symbol.
+@item @var{vector}
+A vector of 128 elements binds all the ASCII characters; the @var{n}th
+element holds the binding for character number @var{n}.
+@item @code{(t . @var{binding})}
+A cons cell whose @sc{car} is @code{t} is a default binding; anything
+not bound by previous keymap elements is given @var{binding} as its
+binding.
+Default bindings are important because they allow a keymap to bind all
+possible events without having to enumerate all the possible function
+keys and mouse clicks, with all possible modifier prefixes.
+The function @code{lookup-key} (and likewise other functions for
+examining a key binding) normally report only explicit bindings of the
+specified key sequence; if there is none, they return @code{nil}, even
+if there is a default binding that would apply to that key sequence if
+it were actually typed in.  However, these functions now take an
+optional argument @var{accept-defaults} which, if non-@code{nil}, says
+to consider default bindings.
+Note that if a vector in the keymap binds an ASCII character to
+@code{nil} (thus making it ``unbound''), the default binding does not
+apply to the character.  Think of the vector element as an explicit
+binding of @code{nil}.
+Note also that if the keymap for a minor or major mode contains a
+default binding, it completely masks out any lower-priority keymaps.
+@end table
+@item
+A keymap can now inherit from another keymap.  To do this, make the
+latter keymap the ``tail'' of the new one.  Such a keymap looks like
+this:
+@example
+(keymap @var{bindings}@dots{} . @var{other-keymap})
+@end example
+The effect is that this keymap inherits all the bindings of
+@var{other-keymap}, but can add to them or override them with
+@var{bindings}.  Subsequent changes in the bindings of
+@var{other-keymap} @emph{do} affect this keymap.
+For example,
+@example
+(setq my-mode-map (cons 'keymap text-mode-map))
+@end example
+@noindent
+makes a keymap that by default inherits all the bindings of Text
+mode---whatever they may be at the time a key is looked up.  Any
+bindings made explicitly in @code{my-mode-map} override the bindings
+inherited from Text mode, however.
+@item
+Minor modes can now have local keymaps.  Thus, a key can act a special
+way when a minor mode is in effect, and then revert to the major mode or
+global definition when the minor mode is no longer in effect.  The
+precedence of keymaps is now: minor modes (in no particular order), then
+major mode, and lastly the global map.
+The new @code{current-minor-mode-maps} function returns a list of all
+the keymaps of currently enabled minor modes, in the other that they
+apply.
+To set up a keymap for a minor mode, add an element to the alist
+@code{minor-mode-map-alist}.  Its elements look like this:
+@example
+(@var{symbol} . @var{keymap})
+@end example
+The keymap @var{keymap} is active whenever @var{symbol} has a
+non-@code{nil} value.  Use for @var{symbol} the variable which indicates
+whether the minor mode is enabled.
+When more than one minor mode keymap is active, their order of
+precedence is the order of @code{minor-mode-map-alist}.  But you should
+design minor modes so that they don't interfere with each other, and if
+you do this properly, the order will not matter.
+The function @code{minor-mode-key-binding} returns a list of all the
+active minor mode bindings of @var{key}.  More precisely, it returns an
+alist of pairs @code{(@var{modename} . @var{binding})}, where
+@var{modename} is the the variable which enables the minor mode, and
+@var{binding} is @var{key}'s definition in that mode.  If @var{key} has
+no minor-mode bindings, the value is @code{nil}.
+If the first binding is a non-prefix, all subsequent bindings from other
+minor modes are omitted, since they would be completely shadowed.
+Similarly, the list omits non-prefix bindings that follow prefix
+bindings.
+@item
+The new function @code{copy-keymap} copies a keymap, producing a new
+keymap with the same key bindings in it.  If the keymap contains other
+keymaps directly, these subkeymaps are copied recursively.
+If you want to, you can define a prefix key with a binding that is a
+symbol whose function definition is another keymap.  In this case,
+@code{copy-keymap} does not look past the symbol; it doesn't copy the
+keymap inside the symbol.
+@item
+@code{substitute-key-definition} now accepts an optional fourth
+argument, which is a keymap to use as a template.
+@example
+(substitute-key-definition olddef newdef keymap oldmap)
+@end example
+@noindent
+finds all characters defined in @var{oldmap} as @var{olddef},
+and defines them in @var{keymap} as @var{newdef}.
+In addition, this function now operates recursively on the keymaps that
+define prefix keys within @var{keymap} and @var{oldmap}.
+@end itemize
+@section Minibuffer Features
+The minibuffer input functions @code{read-from-minibuffer} and
+@code{completing-read} have new features.
+@subsection Minibuffer History
+A new optional argument @var{hist} specifies which history list to use.
+If you specify a variable (a symbol), that variable is the history
+list.  If you specify a cons cell @code{(@var{variable}
+. @var{startpos})}, then @var{variable} is the history list variable,
+and @var{startpos} specifies the initial history position (an integer,
+counting from zero which specifies the most recent element of the
+history).
+If you specify @var{startpos}, then you should also specify that element
+of the history as @var{initial-input}, for consistency.
+If you don't specify @var{hist}, then the default history list
+@code{minibuffer-history} is used.  Other standard history lists that
+you can use when appropriate include @code{query-replace-history},
+@code{command-history}, and @code{file-name-history}.
+The value of the history list variable is a list of strings, most recent
+first.  You should set a history list variable to @code{nil} before
+using it for the first time.
+@code{read-from-minibuffer} and @code{completing-read} add new elements
+to the history list automatically, and provide commands to allow the
+user to reuse items on the list.  The only thing your program needs to
+do to use a history list is to initialize it and to pass its name to the
+input functions when you wish.  But it is safe to modify the list by
+hand when the minibuffer input functions are not using it.
+@subsection Other Minibuffer Features
+The @var{initial} argument to @code{read-from-minibuffer} and other
+minibuffer input functions can now be a cons cell @code{(@var{string}
+. @var{position})}.  This means to start off with @var{string} in the
+minibuffer, but put the cursor @var{position} characters from the
+beginning, rather than at the end.
+In @code{read-no-blanks-input}, the @var{initial} argument is now
+optional; if it is omitted, the initial input string is the empty
+string.
+@section New Features for Defining Commands
+@itemize @bullet
+@item
+If the interactive specification begins with @samp{@@}, this means to
+select the window under the mouse.  This selection takes place before
+doing anything else with the command.
+You can use both @samp{@@} and @samp{*} together in one command; they
+are processed in order of appearance.
+@item
+Prompts in an interactive specification can incorporate the values of
+the preceding arguments.  Emacs replaces @samp{%}-sequences (as used
+with the @code{format} function) in the prompt with the interactive
+arguments that have been read so far.  For example, a command with this
+interactive specification
+@example
+(interactive "sReplace: \nsReplace %s with: ")
+@end example
+@noindent
+prompts for the first argument with @samp{Replace: }, and then prompts
+for the second argument with @samp{Replace @var{foo} with: }, where
+@var{foo} is the string read as the first argument.
+@item
+If a command name has a property @code{enable-recursive-minibuffers}
+which is non-@code{nil}, then the command can use the minibuffer to read
+arguments even if it is invoked from the minibuffer.  The minibuffer
+command @code{next-matching-history-element} (normally bound to
+@kbd{M-s} in the minibuffer) uses this feature.
+@end itemize
+@section New Features for Reading Input
+@itemize @bullet
+@item
+The function @code{set-input-mode} now takes four arguments.  The last
+argument is optional.  Their names are @var{interrupt}, @var{flow},
+@var{meta} and @var{quit}.
+The argument @var{interrupt} says whether to use interrupt-driven
+input.  Non-@code{nil} means yes, and @code{nil} means no (use CBREAK
+mode).
+The argument @var{flow} says whether to enable terminal flow control.
+Non-@code{nil} means yes.
+The argument @var{meta} controls support for input character codes above
+127.  If @var{meta} is @code{t}, Emacs converts characters with the 8th
+bit set into Meta characters.  If @var{meta} is @code{nil}, Emacs
+disregards the 8th bit; this is necessary when the terminal uses it as a
+parity bit.  If @var{meta} is neither @code{t} nor @code{nil}, Emacs
+uses all 8 bits of input unchanged.  This is good for terminals using
+European 8-bit character sets.
+If @var{quit} non-@code{nil}, it is the character to use for quitting.
+(Normally this is @kbd{C-g}.)
+@item
+The variable @code{meta-flag} has been deleted; use
+@code{set-input-mode} to enable or disable support for a @key{META}
+key.  This change was made because @code{set-input-mode} can send the
+terminal the appropriate commands to enable or disable operation of the
+@key{META} key.
+@item
+The new variable @code{extra-keyboard-modifiers} lets Lisp programs
+``press'' the modifier keys on the keyboard.
+The value is a bit mask:
+@table @asis
+@item 1
+The @key{SHIFT} key.
+@item 2
+The @key{LOCK} key.
+@item 4
+The @key{CTL} key.
+@item 8
+The @key{META} key.
+@end table
+When you use X windows, the program can press any of the modifier keys
+in this way.  Otherwise, only the @key{CTL} and @key{META} keys can be
+virtually pressed.
+@item
+You can use the new function @code{keyboard-translate} to set up
+@code{keyboard-translate-table} conveniently.
+@item
+Y-or-n questions using the @code{y-or-n-p} function now accept @kbd{C-]}
+(usually mapped to @code{abort-recursive-edit}) as well as @kbd{C-g} to
+quit.
+@item
+The variable @code{num-input-keys} is the total number of key sequences
+that the user has typed during this Emacs session.
+@item
+A new Lisp variable, @code{function-key-map}, holds a keymap which
+describes the character sequences sent by function keys on an ordinary
+character terminal.  This uses the same keymap data structure that is
+used to hold bindings of key sequences, but it has a different meaning:
+it specifies translations to make while reading a key sequence.
+If @code{function-key-map} ``binds'' a key sequence @var{k} to a vector
+@var{v}, then when @var{k} appears as a subsequence @emph{anywhere} in a
+key sequence, it is replaced with @var{v}.
+For example, VT100 terminals send @kbd{@key{ESC} O P} when the ``keypad''
+PF1 key is pressed.  Thus, on a VT100, @code{function-key-map} should
+``bind'' that sequence to @code{[pf1]}.  This specifies translation of
+@kbd{@key{ESC} O P} into @key{PF1} anywhere in a key sequence.
+Thus, typing @kbd{C-c @key{PF1}} sends the character sequence @kbd{C-c
+@key{ESC} O P}, but @code{read-key-sequence} translates this back into
+@kbd{C-c @key{PF1}}, which it returns as the vector @code{[?\C-c PF1]}.
+Entries in @code{function-key-map} are ignored if they conflict with
+bindings made in the minor mode, local, or global keymaps.
+The value of @code{function-key-map} is usually set up automatically
+according to the terminal's Terminfo or Termcap entry, and the
+terminal-specific Lisp files.  Emacs comes with a number of
+terminal-specific files for many common terminals; their main purpose is
+to make entries in @code{function-key-map} beyond those that can be
+deduced from Termcap and Terminfo.
+@item
+The variable @code{key-translation-map} works like @code{function-key-map}
+except for two things:
+@itemize @bullet
+@item
+@code{key-translation-map} goes to work after @code{function-key-map} is
+finished; it receives the results of translation by
+@code{function-key-map}.
+@item
+@code{key-translation-map} overrides actual key bindings.
+@end itemize
+The intent of @code{key-translation-map} is for users to map one
+character set to another, including ordinary characters normally bound
+to @code{self-insert-command}.
+@end itemize
+@section New Syntax Table Features
+@itemize @bullet
+@item
+You can use two new functions to move across characters in certain
+syntax classes.
+@code{skip-syntax-forward} moves point forward across characters whose
+syntax classes are mentioned in its first argument, a string.  It stops
+when it encounters the end of the buffer, or position @var{lim} (the
+optional second argument), or a character it is not supposed to skip.
+The function @code{skip-syntax-backward} is similar but moves backward.
+@item
+The new function @code{forward-comment} moves point by comments.  It
+takes one argument, @var{count}; it moves point forward across
+@var{count} comments (backward, if @var{count} is negative).  If it
+finds anything other than a comment or whitespace, it stops, leaving
+point at the far side of the last comment found.  It also stops after
+satisfying @var{count}.
+@item
+The new variable @code{words-include-escapes} affects the behavior of
+@code{forward-word} and everything that uses it.  If it is
+non-@code{nil}, then characters in the ``escape'' and ``character
+quote'' syntax classes count as part of words.
+@item
+There are two new syntax flags for use in syntax tables.
+@itemize -
+@item
+The prefix flag.
+The @samp{p} flag identifies additional ``prefix characters'' in Lisp
+syntax.  You can set this flag with @code{modify-syntax-entry} by
+including the letter @samp{p} in the syntax specification.
+These characters are treated as whitespace when they appear between
+expressions.  When they appear within an expression, they are handled
+according to their usual syntax codes.
+The function @code{backward-prefix-chars} moves back over these
+characters, as well as over characters whose primary syntax class is
+prefix (@samp{'}).
+@item
+The @samp{b} comment style flag.
+Emacs can now supports two comment styles simultaneously.  (This is for
+the sake of C++.)  More specifically, it can recognize two different
+comment-start sequences.  Both must share the same first character; only
+the second character may differ.  Mark the second character of the
+@samp{b}-style comment start sequence with the @samp{b} flag.  You can
+set this flag with @code{modify-syntax-entry} by including the letter
+@samp{b} in the syntax specification.
+The two styles of comment can have different comment-end sequences.  A
+comment-end sequence (one or two characters) applies to the @samp{b}
+style if its first character has the @samp{b} flag set; otherwise, it
+applies to the @samp{a} style.
+The appropriate comment syntax settings for C++ are as follows:
+@table @asis
+@item @samp{/}
+@samp{124b}
+@item @samp{*}
+@samp{23}
+@item newline
+@samp{>b}
+@end table
+Thus @samp{/*} is a comment-start sequence for @samp{a} style, @samp{//}
+is a comment-start sequence for @samp{b} style, @samp{*/} is a
+comment-end sequence for @samp{a} style, and newline is a comment-end
+sequence for @samp{b} style.
+@end itemize
+@end itemize
+@section The Case Table
+You can customize case conversion using the new case table feature.  A
+case table is a collection of strings that specifies the mapping between
+upper case and lower case letters.  Each buffer has its own case table.
+You need a case table if you are using a language which has letters that
+are not standard ASCII letters.
+A case table is a list of this form:
+@example
+(@var{downcase} @var{upcase} @var{canonicalize} @var{equivalences})
+@end example
+@noindent
+where each element is either @code{nil} or a string of length 256.  The
+element @var{downcase} says how to map each character to its lower-case
+equivalent.  The element @var{upcase} maps each character to its
+upper-case equivalent.  If lower and upper case characters are in 1-1
+correspondence, use @code{nil} for @var{upcase}; then Emacs deduces the
+upcase table from @var{downcase}.
+For some languages, upper and lower case letters are not in 1-1
+correspondence.  There may be two different lower case letters with the
+same upper case equivalent.  In these cases, you need to specify the
+maps for both directions.
+The element @var{canonicalize} maps each character to a canonical
+equivalent; any two characters that are related by case-conversion have
+the same canonical equivalent character.
+The element @var{equivalences} is a map that cyclicly permutes each
+equivalence class (of characters with the same canonical equivalent).
+You can provide @code{nil} for both @var{canonicalize} and
+@var{equivalences}, in which case both are deduced from @var{downcase}
+and @var{upcase}.
+Here are the functions for working with case tables:
+@code{case-table-p} is a predicate that says whether a Lisp object is a
+valid case table.
+@code{set-standard-case-table} takes one argument and makes that
+argument the case table for new buffers created subsequently.
+@code{standard-case-table} returns the current value of the new buffer
+case table.
+@code{current-case-table} returns the case table of the current buffer.
+@code{set-case-table} sets the current buffer's case table to the
+argument.
+@code{set-case-syntax-pair} is a convenient function for specifying a
+pair of letters, upper case and lower case.  Call it with two arguments,
+the upper case letter and the lower case letter.  It modifies the
+standard case table and a few syntax tables that are predefined in
+Emacs.  This function is intended as a subroutine for packages that
+define non-ASCII character sets.
+Load the library @file{iso-syntax} to set up the syntax and case table for
+the 256 bit ISO Latin 1 character set.
+@section New Features for Dealing with Buffers
+@itemize @bullet
+@item
+The new function @code{buffer-modified-tick} returns a buffer's
+modification-count that ticks every time the buffer is modified.  It
+takes one optional argument, which is the buffer you want to examine.
+If the argument is @code{nil} (or omitted), the current buffer is used.
+@item
+@code{buffer-disable-undo} is a new name for the function
+formerly known as @code{buffer-flush-undo}.  This turns off recording
+of undo information in the buffer given as argument.
+@item
+The new function @code{generate-new-buffer-name} chooses a name that
+would be unique for a new buffer---but does not create the buffer.  Give
+it one argument, a starting name.  It produces a name not in use for a
+buffer by appending a number inside of @samp{<@dots{}>}.
+@item
+The function @code{rename-buffer} now takes an optional second argument
+which tells it that if the specified new name corresponds to an existing
+buffer, it should use @code{generate-new-buffer-name} to modify the name
+to be unique, rather than signaling an error.
+@code{rename-buffer} now returns the name to which the buffer was
+renamed.
+@item
+The function @code{list-buffers} now looks at the local variable
+@code{list-buffers-directory} in each non-file-visiting buffer, and
+shows its value where the file would normally go.  Dired sets this
+variable in each Dired buffer, so the buffer list now shows which
+directory each Dired buffer is editing.
+@item
+The function @code{other-buffer} now takes an optional second argument
+@var{visible-ok} which, if non-@code{nil}, indicates that buffers
+currently being displayed in windows may be returned even if there are
+other buffers not visible.  Normally, @code{other-buffer} returns a
+currently visible buffer only as a last resort, if there are no suitable
+invisible buffers.
+@item
+The hook @code{kill-buffer-hook} now runs whenever a buffer is killed.
+@end itemize
+@section Local Variables Features
+@itemize @bullet
+@item
+If a local variable name has a non-@code{nil} @code{permanent-local}
+property, then @code{kill-all-local-variables} does not kill it.  Such
+local variables are ``permanent''---they remain unchanged even if you
+select a different major mode.
+Permanent locals are useful when they have to do with where the file
+came from or how to save it, rather than with how to edit the contents.
+@item
+The function @code{make-local-variable} now never changes the value of the variable
+that it makes local.  If the variable had no value before, it still has
+no value after becoming local.
+@item
+The new function @code{default-boundp} tells you whether a variable has
+a default value (as opposed to being unbound in its default value).  If
+@code{(default-boundp 'foo)} returns @code{nil}, then
+@code{(default-value 'foo)} would get an error.
+@code{default-boundp} is to @code{default-value} as @code{boundp} is to
+@code{symbol-value}.
+@item
+The special forms @code{defconst} and @code{defvar}, when the variable
+is local in the current buffer, now set the variable's default value
+rather than its local value.
+@end itemize
+@section New Features for Subprocesses
+@itemize @bullet
+@item
+@code{call-process} and @code{call-process-region} now return a value
+that indicates how the synchronous subprocess terminated.  It is either
+a number, which is the exit status of a process, or a signal name
+represented as a string.
+@item
+@code{process-status} now returns @code{open} and @code{closed} as the
+status values for network connections.
+@item
+The standard asynchronous subprocess features work on VMS now,
+and the special VMS asynchronous subprocess functions have been deleted.
+@item
+You can use the transaction queue feature for more convenient
+communication with subprocesses using transactions.
+Call @code{tq-create} to create a transaction queue communicating with a
+specified process.  Then you can call @code{tq-enqueue} to send a
+transaction.  @code{tq-enqueue} takes these five arguments:
+@example
+(tq-enqueue @var{tq} @var{question} @var{regexp} @var{closure} @var{fn})
+@end example
+@var{tq} is the queue to use.  (Specifying the queue has the effect of
+specifying the process to talk to.)  The argument @var{question} is the
+outgoing message which starts the transaction.  The argument @var{fn} is
+the function to call when the corresponding answer comes back; it is
+called with two arguments: @var{closure}, and the answer received.
+The argument @var{regexp} is a regular expression to match the entire
+answer; that's how @code{tq-enqueue} tells where the answer ends.
+Call @code{tq-close} to shut down a transaction queue and terminate its
+subprocess.
+@item
+The function @code{signal-process} sends a signal to process @var{pid},
+which need not be a child of Emacs.  The second argument @var{signal}
+specifies which signal to send; it should be an integer.
+@end itemize
+@section New Features for Dealing with Times And Time Delays
+@itemize @bullet
+@item
+The new function @code{current-time} returns the system's time value as
+a list of three integers: @code{(@var{high} @var{low} @var{microsec})}.
+The integers @var{high} and @var{low} combine to give the number of
+seconds since 0:00 January 1, 1970, which is @var{high} * 2**16 +
+@var{low}.
+@var{microsec} gives the microseconds since the start of the current
+second (or 0 for systems that return time only on the resolution of a
+second).
+@item
+The function @code{current-time-string} accepts an optional argument
+@var{time-value}.  If given, this specifies a time to format instead of
+the current time.  The argument should be a cons cell containing two
+integers, or a list whose first two elements are integers.  Thus, you
+can use times obtained from @code{current-time} (see above) and from
+@code{file-attributes}.
+@item
+You can now find out the user's time zone using @code{current-time-zone}.
+The value has the form @code{(@var{OFFSET} @var{name})}.  Here
+@var{offset} is an integer giving the number of seconds ahead of UTC
+(east of Greenwich).  A negative value means west of Greenwich.  The
+second element, @var{name} is a string giving the name of the time
+zone.  Both elements change when daylight savings time begins or ends;
+if the user has specified a time zone that does not use a seasonal time
+adjustment, then the value is constant through time.
+If the operating system doesn't supply all the information necessary to
+compute the value, both elements of the list are @code{nil}.
+The optional argument @var{time-value}, if given, specifies a time to
+analyze instead of the current time.  The argument should be a cons cell
+containing two integers, or a list whose first two elements are
+integers.  Thus, you can use times obtained from @code{current-time} and
+from @code{file-attributes}.
+@item
+@code{sit-for}, @code{sleep-for} now let you specify the time period in
+milliseconds as well as in seconds.  The first argument gives the number
+of seconds, as before, and the optional second argument gives additional
+milliseconds.  The time periods specified by these two arguments are
+added together.
+Not all systems support this; you get an error if you specify nonzero
+milliseconds and it isn't supported.
+@code{sit-for} also accepts an optional third argument @var{nodisp}.  If
+this is non-@code{nil}, @code{sit-for} does not redisplay.  It still
+waits for the specified time or until input is available.
+@item
+@code{accept-process-output} now accepts a timeout specified by optional
+second and third arguments.  The second argument specifies the number of
+seconds, while the third specifies the number of milliseconds.  The time
+periods specified by these two arguments are added together.
+Not all systems support this; you get an error if you specify nonzero
+milliseconds and it isn't supported.
+The function returns @code{nil} if the timeout expired before output
+arrived, or non-@code{nil} if it did get some output.
+@item
+You can set up a timer to call a function at a specified future time.
+To do so, call @code{run-at-time}, like this:
+@example
+(run-at-time @var{time} @var{repeat} @var{function} @var{args}@dots{})
+@end example
+Here, @var{time} is a string saying when to call the function.  The
+argument @var{function} is the function to call later, and @var{args}
+are the arguments to give it when it is called.
+The argument @var{repeat} specifies how often to repeat the call.  If
+@var{repeat} is @code{nil}, there are no repetitions; @var{function} is
+called just once, at @var{time}.  If @var{repeat} is an integer, it
+specifies a repetition period measured in seconds.
+Absolute times may be specified in a wide variety of formats; The form
+@samp{@var{hour}:@var{min}:@var{sec} @var{timezone}
+@var{month}/@var{day}/@var{year}}, where all fields are numbers, works;
+the format that @code{current-time-string} returns is also allowed.
+To specify a relative time, use numbers followed by units.
+For example:
+@table @samp
+@item 1 min
+denotes 1 minute from now.
+@item 1 min 5 sec
+denotes 65 seconds from now.
+@item 1 min 2 sec 3 hour 4 day 5 week 6 fortnight 7 month 8 year
+denotes exactly 103 months, 123 days, and 10862 seconds from now.
+@end table
+If @var{time} is an integer, that specifies a relative time measured in
+seconds.
+@end itemize
+To cancel the requested future action, pass the value that @code{run-at-time}
+returned to the function @code{cancel-timer}.
+@section Profiling Lisp Programs
+You can now make execution-time profiles of Emacs Lisp programs using
+the @file{profile} library.  See the file @file{profile.el} for
+instructions; if you have written a Lisp program big enough to be worth
+profiling, you can surely understand them.
+@section New Features for Lisp Debuggers
+@itemize @bullet
+@item
+You can now specify which kinds of errors should invoke the Lisp
+debugger by setting the variable @code{debug-on-error} to a list of error
+conditions.  For example, if you set it to the list @code{(void-variable)},
+then only errors about a variable that has no value invoke the
+debugger.
+@item
+The variable @code{command-debug-status} is used by Lisp debuggers.  It
+records the debugging status of current interactive command.  Each time
+a command is called interactively, this variable is bound to
+@code{nil}.  The debugger can set this variable to leave information for
+future debugger invocations during the same command.
+The advantage of this variable over some other variable in the debugger
+itself is that the data will not be visible for any other command
+invocation.
+@item
+The function @code{backtrace-frame} is intended for use in Lisp
+debuggers.  It returns information about what a frame on the Lisp call
+stack is doing.  You specify one argument, which is the number of stack
+frames to count up from the current execution point.
+If that stack frame has not evaluated the arguments yet (or is a special
+form), the value is @code{(nil @var{function} @var{arg-forms}@dots{})}.
+If that stack frame has evaluated its arguments and called its function
+already, the value is @code{(t @var{function}
+@var{arg-values}@dots{})}.
+In the return value, @var{function} is whatever was supplied as @sc{car}
+of evaluated list, or a @code{lambda} expression in the case of a macro
+call.  If the function has a @code{&rest} argument, that is represented
+as the tail of the list @var{arg-values}.
+If the argument is out of range, @code{backtrace-frame} returns
+@code{nil}.
+@end itemize
+@ignore
+@item
+@code{kill-ring-save} now gives visual feedback to indicate the region
+of text being added to the kill ring.  If the opposite end of the
+region is visible in the current window, the cursor blinks there.
+Otherwise, some text from the other end of the region is displayed in
+the message area.
+@end ignore
+@section Memory Allocation Changes
+The list that @code{garbage-collect} returns now has one additional
+element.  This is a cons cell containing two numbers.  It gives
+information about the number of used and free floating point numbers,
+much as the first element gives such information about the number of
+used and free cons cells.
+The new function @code{memory-limit} returns an indication of the last
+address allocated by Emacs.  More precisely, it returns that address
+divided by 1024.  You can use this to get a general idea of how your
+actions affect the memory usage.
+@section Hook Changes
+@itemize @bullet
+@item
+Expanding an abbrev first runs the new hook
+@code{pre-abbrev-expand-hook}.
+@item
+The editor command loop runs the normal hook @code{pre-command-hook}
+before each command, and runs @code{post-command-hook} after each
+command.
+@item
+Auto-saving runs the new hook @code{auto-save-hook} before actually
+starting to save any files.
+@item
+The new variable @code{revert-buffer-insert-file-contents-function}
+holds a function that @code{revert-buffer} now uses to read in the
+contents of the reverted buffer---instead of calling
+@code{insert-file-contents}.
+@item
+The variable @code{lisp-indent-hook} has been renamed to
+@code{lisp-indent-function}.
+@item
+The variable @code{auto-fill-hook} has been renamed to
+@code{auto-fill-function}.
+@item
+The variable @code{blink-paren-hook} has been renamed to
+@code{blink-paren-function}.
+@item
+The variable @code{temp-buffer-show-hook} has been renamed to
+@code{temp-buffer-show-function}.
+@item
+The variable @code{suspend-hook} is now a normal hook.
+It used to be a special kind of hook; its value had to be a single
+function, and if the function returned a non-@code{nil} value,
+then suspension was inhibited.
+@item
+The new function @code{add-hook} provides a handy way to add a function
+to a hook variable.  For example,
+@example
+(add-hook 'text-mode-hook 'my-text-hook-function)
+@end example
+@noindent
+arranges to call @code{my-text-hook-function}
+when entering Text mode or related modes.
+@code{add-hook} takes an optional third argument which says to add the
+new hook function at the end of the list (normally, it goes at the
+beginning).
+@end itemize
+@bye

Mercurial > hg > xemacs-beta

comparison etc/news.texi @ 0:376386a54a3c r19-14