mirror of
https://git.savannah.gnu.org/git/emacs.git
synced 2024-11-21 06:55:39 +00:00
94bf7ad797
* doc/lispref/display.texi (Overlay Properties): * doc/lispref/text.texi (Special Properties): Document 'display-line-numbers-disable'. Fix indexing.
6566 lines
267 KiB
Plaintext
6566 lines
267 KiB
Plaintext
@c -*-texinfo-*-
|
|
@c This is part of the GNU Emacs Lisp Reference Manual.
|
|
@c Copyright (C) 1990--1995, 1998--2024 Free Software Foundation, Inc.
|
|
@c See the file elisp.texi for copying conditions.
|
|
@node Text
|
|
@chapter Text
|
|
@cindex text
|
|
|
|
This chapter describes the functions that deal with the text in a
|
|
buffer. Most examine, insert, or delete text in the current buffer,
|
|
often operating at point or on text adjacent to point. Many are
|
|
interactive. All the functions that change the text provide for undoing
|
|
the changes (@pxref{Undo}).
|
|
|
|
Many text-related functions operate on a region of text defined by two
|
|
buffer positions passed in arguments named @var{start} and @var{end}.
|
|
These arguments should be either markers (@pxref{Markers}) or numeric
|
|
character positions (@pxref{Positions}). The order of these arguments
|
|
does not matter; it is all right for @var{start} to be the end of the
|
|
region and @var{end} the beginning. For example, @code{(delete-region 1
|
|
10)} and @code{(delete-region 10 1)} are equivalent. An
|
|
@code{args-out-of-range} error is signaled if either @var{start} or
|
|
@var{end} is outside the accessible portion of the buffer. In an
|
|
interactive call, point and the mark are used for these arguments.
|
|
|
|
@cindex buffer contents
|
|
Throughout this chapter, ``text'' refers to the characters in the
|
|
buffer, together with their properties (when relevant). Keep in mind
|
|
that point is always between two characters, and the cursor appears on
|
|
the character after point.
|
|
|
|
@menu
|
|
* Near Point:: Examining text in the vicinity of point.
|
|
* Buffer Contents:: Examining text in a general fashion.
|
|
* Comparing Text:: Comparing substrings of buffers.
|
|
* Insertion:: Adding new text to a buffer.
|
|
* Commands for Insertion:: User-level commands to insert text.
|
|
* Deletion:: Removing text from a buffer.
|
|
* User-Level Deletion:: User-level commands to delete text.
|
|
* The Kill Ring:: Where removed text sometimes is saved for later use.
|
|
* Undo:: Undoing changes to the text of a buffer.
|
|
* Maintaining Undo:: How to enable and disable undo information.
|
|
How to control how much information is kept.
|
|
* Filling:: Functions for explicit filling.
|
|
* Margins:: How to specify margins for filling commands.
|
|
* Adaptive Fill:: Adaptive Fill mode chooses a fill prefix from context.
|
|
* Auto Filling:: How auto-fill mode is implemented to break lines.
|
|
* Sorting:: Functions for sorting parts of the buffer.
|
|
* Columns:: Computing horizontal positions, and using them.
|
|
* Indentation:: Functions to insert or adjust indentation.
|
|
* Case Changes:: Case conversion of parts of the buffer.
|
|
* Text Properties:: Assigning Lisp property lists to text characters.
|
|
* Substitution:: Replacing a given character wherever it appears.
|
|
* Registers:: How registers are implemented. Accessing the text or
|
|
position stored in a register.
|
|
* Transposition:: Swapping two portions of a buffer.
|
|
* Replacing:: Replacing the text of one buffer with the text
|
|
of another buffer.
|
|
* Decompression:: Dealing with compressed data.
|
|
* Base 64:: Conversion to or from base 64 encoding.
|
|
* Checksum/Hash:: Computing cryptographic hashes.
|
|
* Suspicious Text:: Determining whether a string is suspicious.
|
|
* GnuTLS Cryptography:: Cryptographic algorithms imported from GnuTLS.
|
|
* Database:: Interacting with an SQL database.
|
|
* Parsing HTML/XML:: Parsing HTML and XML.
|
|
* Parsing JSON:: Parsing and generating JSON values.
|
|
* JSONRPC:: JSON Remote Procedure Call protocol
|
|
* Atomic Changes:: Installing several buffer changes atomically.
|
|
* Change Hooks:: Supplying functions to be run when text is changed.
|
|
@end menu
|
|
|
|
@node Near Point
|
|
@section Examining Text Near Point
|
|
@cindex text near point
|
|
|
|
Many functions are provided to look at the characters around point.
|
|
Several simple functions are described here. See also @code{looking-at}
|
|
in @ref{Regexp Search}.
|
|
|
|
In the following four functions, ``beginning'' or ``end'' of buffer
|
|
refers to the beginning or end of the accessible portion.
|
|
|
|
@defun char-after &optional position
|
|
This function returns the character in the current buffer at (i.e.,
|
|
immediately after) position @var{position}. If @var{position} is out of
|
|
range for this purpose, either before the beginning of the buffer, or at
|
|
or beyond the end, then the value is @code{nil}. The default for
|
|
@var{position} is point.
|
|
|
|
In the following example, assume that the first character in the
|
|
buffer is @samp{@@}:
|
|
|
|
@example
|
|
@group
|
|
(string (char-after 1))
|
|
@result{} "@@"
|
|
@end group
|
|
@end example
|
|
@end defun
|
|
|
|
@defun char-before &optional position
|
|
This function returns the character in the current buffer immediately
|
|
before position @var{position}. If @var{position} is out of range for
|
|
this purpose, either at or before the beginning of the buffer, or beyond
|
|
the end, then the value is @code{nil}. The default for
|
|
@var{position} is point.
|
|
@end defun
|
|
|
|
@defun following-char
|
|
This function returns the character following point in the current
|
|
buffer. This is similar to @code{(char-after (point))}. However, if
|
|
point is at the end of the buffer, then @code{following-char} returns 0.
|
|
|
|
Remember that point is always between characters, and the cursor
|
|
normally appears over the character following point. Therefore, the
|
|
character returned by @code{following-char} is the character the
|
|
cursor is over.
|
|
|
|
In this example, point is between the @samp{a} and the @samp{c}.
|
|
|
|
@example
|
|
@group
|
|
---------- Buffer: foo ----------
|
|
Gentlemen may cry ``Pea@point{}ce! Peace!,''
|
|
but there is no peace.
|
|
---------- Buffer: foo ----------
|
|
@end group
|
|
|
|
@group
|
|
(string (preceding-char))
|
|
@result{} "a"
|
|
(string (following-char))
|
|
@result{} "c"
|
|
@end group
|
|
@end example
|
|
@end defun
|
|
|
|
@defun preceding-char
|
|
This function returns the character preceding point in the current
|
|
buffer. See above, under @code{following-char}, for an example. If
|
|
point is at the beginning of the buffer, @code{preceding-char} returns
|
|
0.
|
|
@end defun
|
|
|
|
@defun bobp
|
|
This function returns @code{t} if point is at the beginning of the
|
|
buffer. If narrowing is in effect, this means the beginning of the
|
|
accessible portion of the text. See also @code{point-min} in
|
|
@ref{Point}.
|
|
@end defun
|
|
|
|
@defun eobp
|
|
This function returns @code{t} if point is at the end of the buffer.
|
|
If narrowing is in effect, this means the end of accessible portion of
|
|
the text. See also @code{point-max} in @xref{Point}.
|
|
@end defun
|
|
|
|
@defun bolp
|
|
This function returns @code{t} if point is at the beginning of a line.
|
|
@xref{Text Lines}. The beginning of the buffer (or of its accessible
|
|
portion) always counts as the beginning of a line.
|
|
@end defun
|
|
|
|
@defun eolp
|
|
This function returns @code{t} if point is at the end of a line. The
|
|
end of the buffer (or of its accessible portion) is always considered
|
|
the end of a line.
|
|
@end defun
|
|
|
|
@node Buffer Contents
|
|
@section Examining Buffer Contents
|
|
@cindex buffer portion as string
|
|
|
|
This section describes functions that allow a Lisp program to
|
|
convert any portion of the text in the buffer into a string.
|
|
|
|
@defun buffer-substring start end
|
|
This function returns a string containing a copy of the text of the
|
|
region defined by positions @var{start} and @var{end} in the current
|
|
buffer. If the arguments are not positions in the accessible portion
|
|
of the buffer, @code{buffer-substring} signals an
|
|
@code{args-out-of-range} error.
|
|
|
|
Here's an example which assumes Font-Lock mode is not enabled:
|
|
|
|
@example
|
|
@group
|
|
---------- Buffer: foo ----------
|
|
This is the contents of buffer foo
|
|
|
|
---------- Buffer: foo ----------
|
|
@end group
|
|
|
|
@group
|
|
(buffer-substring 1 10)
|
|
@result{} "This is t"
|
|
@end group
|
|
@group
|
|
(buffer-substring (point-max) 10)
|
|
@result{} "he contents of buffer foo\n"
|
|
@end group
|
|
@end example
|
|
|
|
If the text being copied has any text properties, these are copied into
|
|
the string along with the characters they belong to. @xref{Text
|
|
Properties}. However, overlays (@pxref{Overlays}) in the buffer and
|
|
their properties are ignored, not copied.
|
|
|
|
For example, if Font-Lock mode is enabled, you might get results like
|
|
these:
|
|
|
|
@example
|
|
@group
|
|
(buffer-substring 1 10)
|
|
@result{} #("This is t" 0 1 (fontified t) 1 9 (fontified t))
|
|
@end group
|
|
@end example
|
|
@end defun
|
|
|
|
@defun buffer-substring-no-properties start end
|
|
This is like @code{buffer-substring}, except that it does not copy text
|
|
properties, just the characters themselves. @xref{Text Properties}.
|
|
@end defun
|
|
|
|
@defun buffer-string
|
|
This function returns the contents of the entire accessible portion of
|
|
the current buffer, as a string. If the text being copied has any
|
|
text properties, these are copied into the string along with the
|
|
characters they belong to.
|
|
@end defun
|
|
|
|
If you need to make sure the resulting string, when copied to a
|
|
different location, will not change its visual appearance due to
|
|
reordering of bidirectional text, use the
|
|
@code{buffer-substring-with-bidi-context} function
|
|
(@pxref{Bidirectional Display, buffer-substring-with-bidi-context}).
|
|
|
|
@defun filter-buffer-substring start end &optional delete
|
|
This function filters the buffer text between @var{start} and @var{end}
|
|
using a function specified by the variable
|
|
@code{filter-buffer-substring-function}, and returns the result.
|
|
|
|
The default filter function consults the obsolete wrapper hook
|
|
@code{filter-buffer-substring-functions} (see the documentation string
|
|
of the macro @code{with-wrapper-hook} for the details about this
|
|
obsolete facility). If it is @code{nil}, it returns the unaltered
|
|
text from the buffer, i.e., what @code{buffer-substring} would return.
|
|
|
|
If @var{delete} is non-@code{nil}, the function deletes the text
|
|
between @var{start} and @var{end} after copying it, like
|
|
@code{delete-and-extract-region}.
|
|
|
|
Lisp code should use this function instead of @code{buffer-substring},
|
|
@code{buffer-substring-no-properties},
|
|
or @code{delete-and-extract-region} when copying into user-accessible
|
|
data structures such as the kill-ring, X clipboard, and registers.
|
|
Major and minor modes can modify @code{filter-buffer-substring-function}
|
|
to alter such text as it is copied out of the buffer.
|
|
@end defun
|
|
|
|
@defvar filter-buffer-substring-function
|
|
The value of this variable is a function that @code{filter-buffer-substring}
|
|
will call to do the actual work. The function receives three
|
|
arguments, the same as those of @code{filter-buffer-substring},
|
|
which it should treat as per the documentation of that function. It
|
|
should return the filtered text (and optionally delete the source text).
|
|
@end defvar
|
|
|
|
@noindent The following two variables are obsoleted by
|
|
@code{filter-buffer-substring-function}, but are still supported for
|
|
backward compatibility.
|
|
|
|
@defvar filter-buffer-substring-functions
|
|
This obsolete variable is a wrapper hook, whose members should be functions
|
|
that accept four arguments: @var{fun}, @var{start}, @var{end}, and
|
|
@var{delete}. @var{fun} is a function that takes three arguments
|
|
(@var{start}, @var{end}, and @var{delete}), and returns a string. In
|
|
both cases, the @var{start}, @var{end}, and @var{delete} arguments are
|
|
the same as those of @code{filter-buffer-substring}.
|
|
|
|
The first hook function is passed a @var{fun} that is equivalent to
|
|
the default operation of @code{filter-buffer-substring}, i.e., it
|
|
returns the buffer-substring between @var{start} and @var{end} and
|
|
optionally deletes the original text from the buffer. In most cases,
|
|
the hook function will call @var{fun} once, and then do its own
|
|
processing of the result. The next hook function receives a @var{fun}
|
|
equivalent to this, and so on. The actual return value is the result
|
|
of all the hook functions acting in sequence.
|
|
@end defvar
|
|
|
|
@defun current-word &optional strict really-word
|
|
This function returns the symbol (or word) at or near point, as a
|
|
string. The return value includes no text properties.
|
|
|
|
If the optional argument @var{really-word} is non-@code{nil}, it finds a
|
|
word; otherwise, it finds a symbol (which includes both word
|
|
characters and symbol constituent characters).
|
|
|
|
If the optional argument @var{strict} is non-@code{nil}, then point
|
|
must be in or next to the symbol or word---if no symbol or word is
|
|
there, the function returns @code{nil}. Otherwise, a nearby symbol or
|
|
word on the same line is acceptable.
|
|
@end defun
|
|
|
|
@defun thing-at-point thing &optional no-properties
|
|
Return the @var{thing} around or next to point, as a string.
|
|
|
|
The argument @var{thing} is a symbol which specifies a kind of
|
|
syntactic entity. Possibilities include @code{symbol}, @code{list},
|
|
@code{sexp}, @code{defun}, @code{filename}, @code{existing-filename},
|
|
@code{url}, @code{word}, @code{sentence}, @code{whitespace},
|
|
@code{line}, @code{page}, @code{string}, and others.
|
|
|
|
When the optional argument @var{no-properties} is non-@code{nil}, this
|
|
function strips text properties from the return value.
|
|
|
|
@example
|
|
---------- Buffer: foo ----------
|
|
Gentlemen may cry ``Pea@point{}ce! Peace!,''
|
|
but there is no peace.
|
|
---------- Buffer: foo ----------
|
|
|
|
(thing-at-point 'word)
|
|
@result{} "Peace"
|
|
(thing-at-point 'line)
|
|
@result{} "Gentlemen may cry ``Peace! Peace!,''\n"
|
|
(thing-at-point 'whitespace)
|
|
@result{} nil
|
|
@end example
|
|
|
|
@defvar thing-at-point-provider-alist
|
|
This variable allows users and modes to tweak how
|
|
@code{thing-at-point} works. It's an association list of @var{thing}s
|
|
and functions (called with zero parameters) to return that thing.
|
|
Entries for @var{thing} will be evaluated in turn until a
|
|
non-@code{nil} result is returned.
|
|
|
|
For instance, a major mode could say:
|
|
|
|
@lisp
|
|
(setq-local thing-at-point-provider-alist
|
|
(append thing-at-point-provider-alist
|
|
'((url . my-mode--url-at-point))))
|
|
@end lisp
|
|
|
|
If no providers have a non-@code{nil} return, the @var{thing} will be
|
|
computed the standard way.
|
|
@end defvar
|
|
@end defun
|
|
|
|
@node Comparing Text
|
|
@section Comparing Text
|
|
@cindex comparing buffer text
|
|
|
|
This function lets you compare portions of the text in a buffer, without
|
|
copying them into strings first.
|
|
|
|
@defun compare-buffer-substrings buffer1 start1 end1 buffer2 start2 end2
|
|
This function lets you compare two substrings of the same buffer or two
|
|
different buffers. The first three arguments specify one substring,
|
|
giving a buffer (or a buffer name) and two positions within the
|
|
buffer. The last three arguments specify the other substring in the
|
|
same way. You can use @code{nil} for @var{buffer1}, @var{buffer2}, or
|
|
both to stand for the current buffer.
|
|
|
|
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 differing characters
|
|
within the substrings.
|
|
|
|
This function ignores case when comparing characters
|
|
if @code{case-fold-search} is non-@code{nil}. It always ignores
|
|
text properties.
|
|
|
|
Suppose you have the text @w{@samp{foobarbar haha!rara!}} in the
|
|
current buffer; then in this example the two substrings are @samp{rbar
|
|
} and @samp{rara!}. The value is 2 because the first substring is
|
|
greater at the second character.
|
|
|
|
@example
|
|
(compare-buffer-substrings nil 6 11 nil 16 21)
|
|
@result{} 2
|
|
@end example
|
|
@end defun
|
|
|
|
@node Insertion
|
|
@section Inserting Text
|
|
@cindex insertion of text
|
|
@cindex text insertion
|
|
|
|
@cindex insertion before point
|
|
@cindex before point, insertion
|
|
@dfn{Insertion} means adding new text to a buffer. The inserted text
|
|
goes at point---between the character before point and the character
|
|
after point. Some insertion functions leave point before the inserted
|
|
text, while other functions leave it after. We call the former
|
|
insertion @dfn{after point} and the latter insertion @dfn{before point}.
|
|
|
|
Insertion moves markers located at positions after the insertion
|
|
point, so that they stay with the surrounding text (@pxref{Markers}).
|
|
When a marker points at the place of insertion, insertion may or may
|
|
not relocate the marker, depending on the marker's insertion type
|
|
(@pxref{Marker Insertion Types}). Certain special functions such as
|
|
@code{insert-before-markers} relocate all such markers to point after
|
|
the inserted text, regardless of the markers' insertion type.
|
|
|
|
Insertion functions signal an error if the current buffer is
|
|
read-only (@pxref{Read Only Buffers}) or if they insert within
|
|
read-only text (@pxref{Special Properties}).
|
|
|
|
These functions copy text characters from strings and buffers along
|
|
with their properties. The inserted characters have exactly the same
|
|
properties as the characters they were copied from. By contrast,
|
|
characters specified as separate arguments, not part of a string or
|
|
buffer, inherit their text properties from the neighboring text.
|
|
|
|
The insertion functions convert text from unibyte to multibyte in
|
|
order to insert in a multibyte buffer, and vice versa---if the text
|
|
comes from a string or from a buffer. However, they do not convert
|
|
unibyte character codes 128 through 255 to multibyte characters, not
|
|
even if the current buffer is a multibyte buffer. @xref{Converting
|
|
Representations}.
|
|
|
|
@defun insert &rest args
|
|
This function inserts the strings and/or characters @var{args} into the
|
|
current buffer, at point, moving point forward. In other words, it
|
|
inserts the text before point. An error is signaled unless all
|
|
@var{args} are either strings or characters. The value is @code{nil}.
|
|
@end defun
|
|
|
|
@defun insert-before-markers &rest args
|
|
This function inserts the strings and/or characters @var{args} into the
|
|
current buffer, at point, moving point forward. An error is signaled
|
|
unless all @var{args} are either strings or characters. The value is
|
|
@code{nil}.
|
|
|
|
This function is unlike the other insertion functions in that it
|
|
relocates markers initially pointing at the insertion point, to point
|
|
after the inserted text. If an overlay begins at the insertion point,
|
|
the inserted text falls outside the overlay; if a nonempty overlay
|
|
ends at the insertion point, the inserted text falls inside that
|
|
overlay.
|
|
@end defun
|
|
|
|
@deffn Command insert-char character &optional count inherit
|
|
This command inserts @var{count} instances of @var{character} into the
|
|
current buffer before point. The argument @var{count} must be an
|
|
integer, and @var{character} must be a character.
|
|
|
|
If called interactively, this command prompts for @var{character}
|
|
using its Unicode name or its code point. @xref{Inserting Text,,,
|
|
emacs, The GNU Emacs Manual}.
|
|
|
|
This function does not convert unibyte character codes 128 through 255
|
|
to multibyte characters, not even if the current buffer is a multibyte
|
|
buffer. @xref{Converting Representations}.
|
|
|
|
If @var{inherit} is non-@code{nil}, the inserted characters inherit
|
|
sticky text properties from the two characters before and after the
|
|
insertion point. @xref{Sticky Properties}.
|
|
@end deffn
|
|
|
|
@defun insert-buffer-substring from-buffer-or-name &optional start end
|
|
This function inserts a portion of buffer @var{from-buffer-or-name}
|
|
into the current buffer before point. The text inserted is the region
|
|
between @var{start} (inclusive) and @var{end} (exclusive). (These
|
|
arguments default to the beginning and end of the accessible portion
|
|
of that buffer.) This function returns @code{nil}.
|
|
|
|
In this example, the form is executed with buffer @samp{bar} as the
|
|
current buffer. We assume that buffer @samp{bar} is initially empty.
|
|
|
|
@example
|
|
@group
|
|
---------- Buffer: foo ----------
|
|
We hold these truths to be self-evident, that all
|
|
---------- Buffer: foo ----------
|
|
@end group
|
|
|
|
@group
|
|
(insert-buffer-substring "foo" 1 20)
|
|
@result{} nil
|
|
|
|
---------- Buffer: bar ----------
|
|
We hold these truth@point{}
|
|
---------- Buffer: bar ----------
|
|
@end group
|
|
@end example
|
|
@end defun
|
|
|
|
@defun insert-buffer-substring-no-properties from-buffer-or-name &optional start end
|
|
This is like @code{insert-buffer-substring} except that it does not
|
|
copy any text properties.
|
|
@end defun
|
|
|
|
@defun insert-into-buffer to-buffer &optional start end
|
|
This is like @code{insert-buffer-substring}, but works in the opposite
|
|
direction: The text is copied from the current buffer into
|
|
@var{to-buffer}. The block of text is copied to the current point in
|
|
@var{to-buffer}, and point (in that buffer) is advanced to after the
|
|
end of the copied text. Is @code{start}/@code{end} is @code{nil}, the
|
|
entire text in the current buffer is copied over.
|
|
@end defun
|
|
|
|
@xref{Sticky Properties}, for other insertion functions that inherit
|
|
text properties from the nearby text in addition to inserting it.
|
|
Whitespace inserted by indentation functions also inherits text
|
|
properties.
|
|
|
|
@node Commands for Insertion
|
|
@section User-Level Insertion Commands
|
|
|
|
This section describes higher-level commands for inserting text,
|
|
commands intended primarily for the user but useful also in Lisp
|
|
programs.
|
|
|
|
@deffn Command insert-buffer from-buffer-or-name
|
|
This command inserts the entire accessible contents of
|
|
@var{from-buffer-or-name} (which must exist) into the current buffer
|
|
after point. It leaves the mark after the inserted text. The value
|
|
is @code{nil}.
|
|
@end deffn
|
|
|
|
@deffn Command self-insert-command count &optional char
|
|
@cindex character insertion
|
|
@cindex self-insertion
|
|
This command inserts the character @var{char} (the last character typed);
|
|
it does so @var{count} times, before point, and returns @code{nil}.
|
|
Most printing characters are bound to this command. In routine use,
|
|
@code{self-insert-command} is the most frequently called function in Emacs,
|
|
but programs rarely use it except to install it on a keymap.
|
|
|
|
In an interactive call, @var{count} is the numeric prefix argument.
|
|
|
|
@c FIXME: This variable is obsolete since 23.1.
|
|
Self-insertion translates the input character through
|
|
@code{translation-table-for-input}. @xref{Translation of Characters}.
|
|
|
|
This command calls @code{auto-fill-function} whenever that is
|
|
non-@code{nil} and the character inserted is in the table
|
|
@code{auto-fill-chars} (@pxref{Auto Filling}).
|
|
|
|
@c Cross refs reworded to prevent overfull hbox. --rjc 15mar92
|
|
This command performs abbrev expansion if Abbrev mode is enabled and
|
|
the inserted character does not have word-constituent
|
|
syntax. (@xref{Abbrevs}, and @ref{Syntax Class Table}.) It is also
|
|
responsible for calling @code{blink-paren-function} when the inserted
|
|
character has close parenthesis syntax (@pxref{Blinking}).
|
|
|
|
@vindex post-self-insert-hook
|
|
@vindex self-insert-uses-region-functions
|
|
The final thing this command does is to run the hook
|
|
@code{post-self-insert-hook}. You could use this to automatically
|
|
reindent text as it is typed, for example. The functions on this hook
|
|
can use @code{last-command-event} (@pxref{Command Loop Info}) to
|
|
access the character just inserted.
|
|
|
|
If any function on this hook needs to act on the region (@pxref{The
|
|
Region}), it should make sure Delete Selection mode (@pxref{Using
|
|
Region, Delete Selection, , emacs, The GNU Emacs Manual}) doesn't
|
|
delete the region before @code{post-self-insert-hook} functions are
|
|
invoked. The way to do so is to add a function that returns
|
|
@code{nil} to @code{self-insert-uses-region-functions}, a special hook
|
|
that tells Delete Selection mode it should not delete the region.
|
|
|
|
Do not try substituting your own definition of
|
|
@code{self-insert-command} for the standard one. The editor command
|
|
loop handles this function specially.
|
|
@end deffn
|
|
|
|
@deffn Command newline &optional number-of-newlines interactive
|
|
This command inserts newlines into the current buffer before point.
|
|
If @var{number-of-newlines} is supplied, that many newline characters
|
|
are inserted. In an interactive call, @var{number-of-newlines} is the
|
|
numeric prefix argument.
|
|
|
|
@cindex newline and Auto Fill mode
|
|
This command calls @code{self-insert-command} to insert newlines,
|
|
which may subsequently break the preceding line by calling
|
|
@code{auto-fill-function} (@pxref{Auto Filling}). Typically what
|
|
@code{auto-fill-function} does is insert a newline; thus, the overall
|
|
result in this case is to insert two newlines at different places: one
|
|
at point, and another earlier in the line. @code{newline} does not
|
|
auto-fill if @var{number-of-newlines} is non-@code{nil}.
|
|
|
|
This command does not run the hook @code{post-self-insert-hook} unless
|
|
called interactively or @var{interactive} is non-@code{nil}.
|
|
|
|
This command indents to the left margin if that is not zero.
|
|
@xref{Margins}.
|
|
|
|
The value returned is @code{nil}.
|
|
@end deffn
|
|
|
|
@deffn Command ensure-empty-lines &optional number-of-empty-lines
|
|
This command can be used to ensure that you have a specific number of
|
|
empty lines before point. (An ``empty line'' is here defined as a
|
|
line with no characters on it---a line with space characters isn't an
|
|
empty line.) It defaults to ensuring that there's a single empty line
|
|
before point.
|
|
|
|
If point isn't at the beginning of a line, a newline character is
|
|
inserted first. If there's more empty lines before point than
|
|
specified, the number of empty lines is reduced. Otherwise it's
|
|
increased to the specified number.
|
|
@end deffn
|
|
|
|
@defvar overwrite-mode
|
|
This variable controls whether overwrite mode is in effect. The value
|
|
should be @code{overwrite-mode-textual}, @code{overwrite-mode-binary},
|
|
or @code{nil}. @code{overwrite-mode-textual} specifies textual
|
|
overwrite mode (treats newlines and tabs specially), and
|
|
@code{overwrite-mode-binary} specifies binary overwrite mode (treats
|
|
newlines and tabs like any other characters).
|
|
@end defvar
|
|
|
|
@node Deletion
|
|
@section Deleting Text
|
|
@cindex text deletion
|
|
|
|
@cindex deleting text vs killing
|
|
Deletion means removing part of the text in a buffer, without saving
|
|
it in the kill ring (@pxref{The Kill Ring}). Deleted text can't be
|
|
yanked, but can be reinserted using the undo mechanism (@pxref{Undo}).
|
|
Some deletion functions do save text in the kill ring in some special
|
|
cases.
|
|
|
|
All of the deletion functions operate on the current buffer.
|
|
|
|
@deffn Command erase-buffer
|
|
This function deletes the entire text of the current buffer
|
|
(@emph{not} just the accessible portion), leaving it
|
|
empty. If the buffer is read-only, it signals a @code{buffer-read-only}
|
|
error; if some of the text in it is read-only, it signals a
|
|
@code{text-read-only} error. Otherwise, it deletes the text without
|
|
asking for any confirmation. It returns @code{nil}.
|
|
|
|
Normally, deleting a large amount of text from a buffer inhibits further
|
|
auto-saving of that buffer because it has shrunk. However,
|
|
@code{erase-buffer} does not do this, the idea being that the future
|
|
text is not really related to the former text, and its size should not
|
|
be compared with that of the former text.
|
|
@end deffn
|
|
|
|
@deffn Command delete-region start end
|
|
This command deletes the text between positions @var{start} and
|
|
@var{end} in the current buffer, and returns @code{nil}. If point was
|
|
inside the deleted region, its value afterward is @var{start}.
|
|
Otherwise, point relocates with the surrounding text, as markers do.
|
|
@end deffn
|
|
|
|
@defun delete-and-extract-region start end
|
|
This function deletes the text between positions @var{start} and
|
|
@var{end} in the current buffer, and returns a string containing the
|
|
text just deleted.
|
|
|
|
If point was inside the deleted region, its value afterward is
|
|
@var{start}. Otherwise, point relocates with the surrounding text, as
|
|
markers do.
|
|
@end defun
|
|
|
|
@deffn Command delete-char count &optional killp
|
|
This command deletes @var{count} characters directly after point, or
|
|
before point if @var{count} is negative. If @var{killp} is
|
|
non-@code{nil}, then it saves the deleted characters in the kill ring.
|
|
|
|
In an interactive call, @var{count} is the numeric prefix argument, and
|
|
@var{killp} is the unprocessed prefix argument. Therefore, if a prefix
|
|
argument is supplied, the text is saved in the kill ring. If no prefix
|
|
argument is supplied, then one character is deleted, but not saved in
|
|
the kill ring.
|
|
|
|
The value returned is always @code{nil}.
|
|
@end deffn
|
|
|
|
@deffn Command delete-backward-char count &optional killp
|
|
@cindex deleting previous char
|
|
This command deletes @var{count} characters directly before point, or
|
|
after point if @var{count} is negative. If @var{killp} is
|
|
non-@code{nil}, then it saves the deleted characters in the kill ring.
|
|
|
|
In an interactive call, @var{count} is the numeric prefix argument, and
|
|
@var{killp} is the unprocessed prefix argument. Therefore, if a prefix
|
|
argument is supplied, the text is saved in the kill ring. If no prefix
|
|
argument is supplied, then one character is deleted, but not saved in
|
|
the kill ring.
|
|
|
|
The value returned is always @code{nil}.
|
|
@end deffn
|
|
|
|
@deffn Command backward-delete-char-untabify count &optional killp
|
|
@cindex tab deletion
|
|
This command deletes @var{count} characters backward, changing tabs
|
|
into spaces. When the next character to be deleted is a tab, it is
|
|
first replaced with the proper number of spaces to preserve alignment
|
|
and then one of those spaces is deleted instead of the tab. If
|
|
@var{killp} is non-@code{nil}, then the command saves the deleted
|
|
characters in the kill ring.
|
|
|
|
Conversion of tabs to spaces happens only if @var{count} is positive.
|
|
If it is negative, exactly @minus{}@var{count} characters after point
|
|
are deleted.
|
|
|
|
In an interactive call, @var{count} is the numeric prefix argument, and
|
|
@var{killp} is the unprocessed prefix argument. Therefore, if a prefix
|
|
argument is supplied, the text is saved in the kill ring. If no prefix
|
|
argument is supplied, then one character is deleted, but not saved in
|
|
the kill ring.
|
|
|
|
The value returned is always @code{nil}.
|
|
@end deffn
|
|
|
|
@defopt backward-delete-char-untabify-method
|
|
This option specifies how @code{backward-delete-char-untabify} should
|
|
deal with whitespace. Possible values include @code{untabify}, the
|
|
default, meaning convert a tab to many spaces and delete one;
|
|
@code{hungry}, meaning delete all tabs and spaces before point with
|
|
one command; @code{all} meaning delete all tabs, spaces and newlines
|
|
before point, and @code{nil}, meaning do nothing special for
|
|
whitespace characters.
|
|
@end defopt
|
|
|
|
@node User-Level Deletion
|
|
@section User-Level Deletion Commands
|
|
|
|
This section describes higher-level commands for deleting text,
|
|
commands intended primarily for the user but useful also in Lisp
|
|
programs.
|
|
|
|
@deffn Command delete-horizontal-space &optional backward-only
|
|
@cindex deleting whitespace
|
|
This function deletes all spaces and tabs around point. It returns
|
|
@code{nil}.
|
|
|
|
If @var{backward-only} is non-@code{nil}, the function deletes
|
|
spaces and tabs before point, but not after point.
|
|
|
|
In the following examples, we call @code{delete-horizontal-space} four
|
|
times, once on each line, with point between the second and third
|
|
characters on the line each time.
|
|
|
|
@example
|
|
@group
|
|
---------- Buffer: foo ----------
|
|
I @point{}thought
|
|
I @point{} thought
|
|
We@point{} thought
|
|
Yo@point{}u thought
|
|
---------- Buffer: foo ----------
|
|
@end group
|
|
|
|
@group
|
|
(delete-horizontal-space) ; @r{Four times.}
|
|
@result{} nil
|
|
|
|
---------- Buffer: foo ----------
|
|
Ithought
|
|
Ithought
|
|
Wethought
|
|
You thought
|
|
---------- Buffer: foo ----------
|
|
@end group
|
|
@end example
|
|
@end deffn
|
|
|
|
@deffn Command delete-indentation &optional join-following-p beg end
|
|
This function joins the line point is on to the previous line, deleting
|
|
any whitespace at the join and in some cases replacing it with one
|
|
space. If @var{join-following-p} is non-@code{nil},
|
|
@code{delete-indentation} joins this line to the following line
|
|
instead. Otherwise, if @var{beg} and @var{end} are non-@code{nil},
|
|
this function joins all lines in the region they define.
|
|
|
|
In an interactive call, @var{join-following-p} is the prefix argument,
|
|
and @var{beg} and @var{end} are, respectively, the start and end of
|
|
the region if it is active, else @code{nil}. The function returns
|
|
@code{nil}.
|
|
|
|
If there is a fill prefix, and the second of the lines being joined
|
|
starts with the prefix, then @code{delete-indentation} deletes the
|
|
fill prefix before joining the lines. @xref{Margins}.
|
|
|
|
In the example below, point is located on the line starting
|
|
@samp{events}, and it makes no difference if there are trailing spaces
|
|
in the preceding line.
|
|
|
|
@smallexample
|
|
@group
|
|
---------- Buffer: foo ----------
|
|
When in the course of human
|
|
@point{} events, it becomes necessary
|
|
---------- Buffer: foo ----------
|
|
@end group
|
|
|
|
(delete-indentation)
|
|
@result{} nil
|
|
|
|
@group
|
|
---------- Buffer: foo ----------
|
|
When in the course of human@point{} events, it becomes necessary
|
|
---------- Buffer: foo ----------
|
|
@end group
|
|
@end smallexample
|
|
|
|
After the lines are joined, the function @code{fixup-whitespace} is
|
|
responsible for deciding whether to leave a space at the junction.
|
|
@end deffn
|
|
|
|
@deffn Command fixup-whitespace
|
|
This function replaces all the horizontal whitespace surrounding point
|
|
with either one space or no space, according to the context. It
|
|
returns @code{nil}.
|
|
|
|
At the beginning or end of a line, the appropriate amount of space is
|
|
none. Before a character with close parenthesis syntax, or after a
|
|
character with open parenthesis or expression-prefix syntax, no space is
|
|
also appropriate. Otherwise, one space is appropriate. @xref{Syntax
|
|
Class Table}.
|
|
|
|
In the example below, @code{fixup-whitespace} is called the first time
|
|
with point before the word @samp{spaces} in the first line. For the
|
|
second invocation, point is directly after the @samp{(}.
|
|
|
|
@smallexample
|
|
@group
|
|
---------- Buffer: foo ----------
|
|
This has too many @point{}spaces
|
|
This has too many spaces at the start of (@point{} this list)
|
|
---------- Buffer: foo ----------
|
|
@end group
|
|
|
|
@group
|
|
(fixup-whitespace)
|
|
@result{} nil
|
|
(fixup-whitespace)
|
|
@result{} nil
|
|
@end group
|
|
|
|
@group
|
|
---------- Buffer: foo ----------
|
|
This has too many spaces
|
|
This has too many spaces at the start of (this list)
|
|
---------- Buffer: foo ----------
|
|
@end group
|
|
@end smallexample
|
|
@end deffn
|
|
|
|
@deffn Command just-one-space &optional n
|
|
@comment !!SourceFile simple.el
|
|
This command replaces any spaces and tabs around point with a single
|
|
space, or @var{n} spaces if @var{n} is specified. It returns
|
|
@code{nil}.
|
|
@end deffn
|
|
|
|
@c There is also cycle-spacing, but I cannot see it being useful in
|
|
@c Lisp programs, so it is not mentioned here.
|
|
|
|
@deffn Command delete-blank-lines
|
|
This function deletes blank lines surrounding point. If point is on a
|
|
blank line with one or more blank lines before or after it, then all but
|
|
one of them are deleted. If point is on an isolated blank line, then it
|
|
is deleted. If point is on a nonblank line, the command deletes all
|
|
blank lines immediately following it.
|
|
|
|
A blank line is defined as a line containing only tabs and spaces.
|
|
@c and the Newline character?
|
|
|
|
@code{delete-blank-lines} returns @code{nil}.
|
|
@end deffn
|
|
|
|
@deffn Command delete-trailing-whitespace &optional start end
|
|
Delete trailing whitespace in the region defined by @var{start} and
|
|
@var{end}.
|
|
|
|
This command deletes whitespace characters after the last
|
|
non-whitespace character in each line in the region.
|
|
|
|
If this command acts on the entire buffer (i.e., if called
|
|
interactively with the mark inactive, or called from Lisp with
|
|
@var{end} @code{nil}), it also deletes all trailing lines at the end of the
|
|
buffer if the variable @code{delete-trailing-lines} is non-@code{nil}.
|
|
@end deffn
|
|
|
|
@node The Kill Ring
|
|
@section The Kill Ring
|
|
@cindex kill ring
|
|
|
|
@dfn{Kill functions} delete text like the deletion functions, but save
|
|
it so that the user can reinsert it by @dfn{yanking}. Most of these
|
|
functions have @samp{kill-} in their name. By contrast, the functions
|
|
whose names start with @samp{delete-} normally do not save text for
|
|
yanking (though they can still be undone); these are deletion
|
|
functions.
|
|
|
|
Most of the kill commands are primarily for interactive use, and are
|
|
not described here. What we do describe are the functions provided for
|
|
use in writing such commands. You can use these functions to write
|
|
commands for killing text. When you need to delete text for internal
|
|
purposes within a Lisp function, you should normally use deletion
|
|
functions, so as not to disturb the kill ring contents.
|
|
@xref{Deletion}.
|
|
|
|
Killed text is saved for later yanking in the @dfn{kill ring}. This
|
|
is a list that holds a number of recent kills, not just the last text
|
|
kill. We call this a ``ring'' because yanking treats it as having
|
|
elements in a cyclic order. The list is kept in the variable
|
|
@code{kill-ring}, and can be operated on with the usual functions for
|
|
lists; there are also specialized functions, described in this section,
|
|
that treat it as a ring.
|
|
|
|
Some people think this use of the word ``kill'' is unfortunate, since
|
|
it refers to operations that specifically @emph{do not} destroy the
|
|
entities killed. This is in sharp contrast to ordinary life, in
|
|
which death is permanent and killed entities do not come back to
|
|
life. Therefore, other metaphors have been proposed. For example, the
|
|
term ``cut ring'' makes sense to people who, in pre-computer days, used
|
|
scissors and paste to cut up and rearrange manuscripts. However, it
|
|
would be difficult to change the terminology now.
|
|
|
|
@menu
|
|
* Kill Ring Concepts:: What text looks like in the kill ring.
|
|
* Kill Functions:: Functions that kill text.
|
|
* Yanking:: How yanking is done.
|
|
* Yank Commands:: Commands that access the kill ring.
|
|
* Low-Level Kill Ring:: Functions and variables for kill ring access.
|
|
* Internals of Kill Ring:: Variables that hold kill ring data.
|
|
@end menu
|
|
|
|
@node Kill Ring Concepts
|
|
@subsection Kill Ring Concepts
|
|
|
|
The kill ring records killed text as strings in a list, most recent
|
|
first. A short kill ring, for example, might look like this:
|
|
|
|
@example
|
|
("some text" "a different piece of text" "even older text")
|
|
@end example
|
|
|
|
@noindent
|
|
When the list reaches @code{kill-ring-max} entries in length, adding a
|
|
new entry automatically deletes the last entry.
|
|
|
|
When kill commands are interwoven with other commands, each kill
|
|
command makes a new entry in the kill ring. Multiple kill commands in
|
|
succession build up a single kill ring entry, which would be yanked as a
|
|
unit; the second and subsequent consecutive kill commands add text to
|
|
the entry made by the first one.
|
|
|
|
For yanking, one entry in the kill ring is designated the front of
|
|
the ring. Some yank commands rotate the ring by designating a
|
|
different element as the front. But this virtual rotation doesn't
|
|
change the list itself---the most recent entry always comes first in the
|
|
list.
|
|
|
|
@node Kill Functions
|
|
@subsection Functions for Killing
|
|
|
|
@code{kill-region} is the usual subroutine for killing text. Any
|
|
command that calls this function is a kill command (and should
|
|
probably have @samp{kill} in its name). @code{kill-region} puts the
|
|
newly killed text in a new element at the beginning of the kill ring or
|
|
adds it to the most recent element. It determines automatically (using
|
|
@code{last-command}) whether the previous command was a kill command,
|
|
and if so appends the killed text to the most recent entry.
|
|
|
|
@cindex filtering killed text
|
|
The commands described below can filter the killed text before they
|
|
save it in the kill ring. They call @code{filter-buffer-substring}
|
|
(@pxref{Buffer Contents}) to perform the filtering. By default,
|
|
there's no filtering, but major and minor modes and hook functions can
|
|
set up filtering, so that text saved in the kill ring is different
|
|
from what was in the buffer.
|
|
|
|
@deffn Command kill-region start end &optional region
|
|
This function kills the stretch of text between @var{start} and
|
|
@var{end}; but if the optional argument @var{region} is
|
|
non-@code{nil}, it ignores @var{start} and @var{end}, and kills the
|
|
text in the current region instead. The text is deleted but saved in
|
|
the kill ring, along with its text properties. The value is always
|
|
@code{nil}.
|
|
|
|
In an interactive call, @var{start} and @var{end} are point and
|
|
the mark, and @var{region} is always non-@code{nil}, so the command
|
|
always kills the text in the current region.
|
|
|
|
If the buffer or text is read-only, @code{kill-region} modifies the kill
|
|
ring just the same, then signals an error without modifying the buffer.
|
|
This is convenient because it lets the user use a series of kill
|
|
commands to copy text from a read-only buffer into the kill ring.
|
|
@end deffn
|
|
|
|
@defopt kill-read-only-ok
|
|
If this option is non-@code{nil}, @code{kill-region} does not signal an
|
|
error if the buffer or text is read-only. Instead, it simply returns,
|
|
updating the kill ring but not changing the buffer.
|
|
@end defopt
|
|
|
|
@deffn Command copy-region-as-kill start end &optional region
|
|
This function saves the stretch of text between @var{start} and
|
|
@var{end} on the kill ring (including text properties), but does not
|
|
delete the text from the buffer. However, if the optional argument
|
|
@var{region} is non-@code{nil}, the function ignores @var{start} and
|
|
@var{end}, and saves the current region instead. It always returns
|
|
@code{nil}.
|
|
|
|
In an interactive call, @var{start} and @var{end} are point and
|
|
the mark, and @var{region} is always non-@code{nil}, so the command
|
|
always saves the text in the current region.
|
|
|
|
The command does not set @code{this-command} to @code{kill-region}, so a
|
|
subsequent kill command does not append to the same kill ring entry.
|
|
@end deffn
|
|
|
|
@node Yanking
|
|
@subsection Yanking
|
|
|
|
Yanking means inserting text from the kill ring, but it does not
|
|
insert the text blindly. The @code{yank} command, and related
|
|
commands, use @code{insert-for-yank} to perform special processing on
|
|
the text before it is inserted.
|
|
|
|
@defun insert-for-yank string
|
|
This function works like @code{insert}, except that it processes the
|
|
text in @var{string} according to the @code{yank-handler} text
|
|
property, as well as the variables @code{yank-handled-properties} and
|
|
@code{yank-excluded-properties} (see below), before inserting the
|
|
result into the current buffer.
|
|
|
|
@var{string} will be run through @code{yank-transform-functions} (see
|
|
below) before inserting.
|
|
@end defun
|
|
|
|
@defun insert-buffer-substring-as-yank buf &optional start end
|
|
This function resembles @code{insert-buffer-substring}, except that it
|
|
processes the text according to @code{yank-handled-properties} and
|
|
@code{yank-excluded-properties}. (It does not handle the
|
|
@code{yank-handler} property, which does not normally occur in buffer
|
|
text anyway.)
|
|
@end defun
|
|
|
|
@c FIXME: Add an index for yank-handler.
|
|
If you put a @code{yank-handler} text property on all or part of a
|
|
string, that alters how @code{insert-for-yank} inserts the string. If
|
|
different parts of the string have different @code{yank-handler}
|
|
values (comparison being done with @code{eq}), each substring is
|
|
handled separately. The property value must be a list of one to four
|
|
elements, with the following format (where elements after the first
|
|
may be omitted):
|
|
|
|
@example
|
|
(@var{function} @var{param} @var{noexclude} @var{undo})
|
|
@end example
|
|
|
|
Here is what the elements do:
|
|
|
|
@table @var
|
|
@item function
|
|
When @var{function} is non-@code{nil}, it is called instead of
|
|
@code{insert} to insert the string, with one argument---the string to
|
|
insert.
|
|
|
|
@item param
|
|
If @var{param} is present and non-@code{nil}, it replaces @var{string}
|
|
(or the substring of @var{string} being processed) as the object
|
|
passed to @var{function} (or @code{insert}). For example, if
|
|
@var{function} is @code{yank-rectangle}, @var{param} should be a list
|
|
of strings to insert as a rectangle.
|
|
|
|
@item noexclude
|
|
If @var{noexclude} is present and non-@code{nil}, that disables the
|
|
normal action of @code{yank-handled-properties} and
|
|
@code{yank-excluded-properties} on the inserted string.
|
|
|
|
@item undo
|
|
If @var{undo} is present and non-@code{nil}, it is a function that will be
|
|
called by @code{yank-pop} to undo the insertion of the current object.
|
|
It is called with two arguments, the start and end of the current
|
|
region. @var{function} can set @code{yank-undo-function} to override
|
|
the @var{undo} value.
|
|
@end table
|
|
|
|
@cindex yanking and text properties
|
|
@defopt yank-handled-properties
|
|
This variable specifies special text property handling conditions for
|
|
yanked text. It takes effect after the text has been inserted (either
|
|
normally, or via the @code{yank-handler} property), and prior to
|
|
@code{yank-excluded-properties} taking effect.
|
|
|
|
The value should be an alist of elements @code{(@var{prop}
|
|
. @var{fun})}. Each alist element is handled in order. The inserted
|
|
text is scanned for stretches of text having text properties @code{eq}
|
|
to @var{prop}; for each such stretch, @var{fun} is called with three
|
|
arguments: the value of the property, and the start and end positions
|
|
of the text.
|
|
@end defopt
|
|
|
|
@defopt yank-excluded-properties
|
|
The value of this variable is the list of properties to remove from
|
|
inserted text. Its default value contains properties that might lead
|
|
to annoying results, such as causing the text to respond to the mouse
|
|
or specifying key bindings. It takes effect after
|
|
@code{yank-handled-properties}.
|
|
@end defopt
|
|
|
|
@defvar yank-transform-functions
|
|
This variable is a list of functions. Each function is called (in
|
|
order) with the string to be yanked as the argument, and should
|
|
return a (possibly transformed) string. This variable can be set
|
|
globally, but can also be used to create new commands that are
|
|
variations on @code{yank}. For instance, to create a command that
|
|
works like @code{yank}, but cleans up whitespace before inserting, you
|
|
could say something like:
|
|
|
|
@lisp
|
|
(defun yank-with-clean-whitespace ()
|
|
(interactive)
|
|
(let ((yank-transform-functions
|
|
'(string-clean-whitespace)))
|
|
(call-interactively #'yank)))
|
|
@end lisp
|
|
@end defvar
|
|
|
|
@node Yank Commands
|
|
@subsection Functions for Yanking
|
|
|
|
This section describes higher-level commands for yanking, which are
|
|
intended primarily for the user but useful also in Lisp programs.
|
|
Both @code{yank} and @code{yank-pop} honor the
|
|
@code{yank-excluded-properties} variable and @code{yank-handler} text
|
|
property (@pxref{Yanking}).
|
|
|
|
@deffn Command yank &optional arg
|
|
@cindex inserting killed text
|
|
This command inserts before point the text at the front of the kill
|
|
ring. It sets the mark at the beginning of that text, using
|
|
@code{push-mark} (@pxref{The Mark}), and puts point at the end.
|
|
|
|
If @var{arg} is a non-@code{nil} list (which occurs interactively when
|
|
the user types @kbd{C-u} with no digits), then @code{yank} inserts the
|
|
text as described above, but puts point before the yanked text and
|
|
sets the mark after it.
|
|
|
|
If @var{arg} is a number, then @code{yank} inserts the @var{arg}th
|
|
most recently killed text---the @var{arg}th element of the kill ring
|
|
list, counted cyclically from the front, which is considered the
|
|
first element for this purpose.
|
|
|
|
@code{yank} does not alter the contents of the kill ring, unless it
|
|
used text provided by another program, in which case it pushes that text
|
|
onto the kill ring. However if @var{arg} is an integer different from
|
|
one, it rotates the kill ring to place the yanked string at the front.
|
|
|
|
@code{yank} returns @code{nil}.
|
|
@end deffn
|
|
|
|
@deffn Command yank-pop &optional arg
|
|
When invoked immediately after a @code{yank} or another
|
|
@code{yank-pop}, this command replaces the just-yanked entry from the
|
|
kill ring with a different entry from the kill ring. When this
|
|
command is invoked like that, the region contains text that was just
|
|
inserted by another yank command. @code{yank-pop} deletes that text
|
|
and inserts in its place a different piece of killed text. It does
|
|
not add the deleted text to the kill ring, since it is already in the
|
|
kill ring somewhere. It does however rotate the kill ring to place
|
|
the newly yanked string at the front.
|
|
|
|
If @var{arg} is @code{nil}, then the replacement text is the previous
|
|
element of the kill ring. If @var{arg} is numeric, the replacement is
|
|
the @var{arg}th previous kill. If @var{arg} is negative, a more recent
|
|
kill is the replacement.
|
|
|
|
The sequence of kills in the kill ring wraps around, so if
|
|
@code{yank-pop} is invoked repeatedly and reaches the oldest kill, the
|
|
one that comes after it is the newest one, and the one before the
|
|
newest one is the oldest one.
|
|
|
|
This command can also be invoked after a command that is not a yank
|
|
command. In that case, it prompts in the minibuffer for a kill-ring
|
|
entry, with completion, and uses the kill ring elements as the
|
|
minibuffer history (@pxref{Minibuffer History}). This allows the user
|
|
to interactively select one of the previous kills recorded in the kill
|
|
ring.
|
|
|
|
The return value is always @code{nil}.
|
|
@end deffn
|
|
|
|
@defvar yank-undo-function
|
|
If this variable is non-@code{nil}, the function @code{yank-pop} uses
|
|
its value instead of @code{delete-region} to delete the text
|
|
inserted by the previous @code{yank} or
|
|
@code{yank-pop} command. The value must be a function of two
|
|
arguments, the start and end of the current region.
|
|
|
|
The function @code{insert-for-yank} automatically sets this variable
|
|
according to the @var{undo} element of the @code{yank-handler}
|
|
text property, if there is one.
|
|
@end defvar
|
|
|
|
@node Low-Level Kill Ring
|
|
@subsection Low-Level Kill Ring
|
|
|
|
These functions and variables provide access to the kill ring at a
|
|
lower level, but are still convenient for use in Lisp programs,
|
|
because they take care of interaction with window system selections
|
|
(@pxref{Window System Selections}).
|
|
|
|
@defun current-kill n &optional do-not-move
|
|
The function @code{current-kill} rotates the yanking pointer, which
|
|
designates the front of the kill ring, by @var{n} places (from newer
|
|
kills to older ones), and returns the text at that place in the ring.
|
|
|
|
If the optional second argument @var{do-not-move} is non-@code{nil},
|
|
then @code{current-kill} doesn't alter the yanking pointer; it just
|
|
returns the @var{n}th kill, counting from the current yanking pointer.
|
|
|
|
If @var{n} is zero, indicating a request for the latest kill,
|
|
@code{current-kill} calls the value of
|
|
@code{interprogram-paste-function} (documented below) before
|
|
consulting the kill ring. If that value is a function and calling it
|
|
returns a string or a list of several strings, @code{current-kill}
|
|
pushes the strings onto the kill ring and returns the first string.
|
|
It also sets the yanking pointer to point to the kill-ring entry of
|
|
the first string returned by @code{interprogram-paste-function},
|
|
regardless of the value of @var{do-not-move}. Otherwise,
|
|
@code{current-kill} does not treat a zero value for @var{n} specially:
|
|
it returns the entry pointed at by the yanking pointer and does not
|
|
move the yanking pointer.
|
|
@end defun
|
|
|
|
@defun kill-new string &optional replace
|
|
This function pushes the text @var{string} onto the kill ring and
|
|
makes the yanking pointer point to it. It discards the oldest entry
|
|
if appropriate. It also invokes the values of
|
|
@code{interprogram-paste-function} (subject to
|
|
the user option @code{save-interprogram-paste-before-kill})
|
|
and @code{interprogram-cut-function} (see below).
|
|
|
|
If @var{replace} is non-@code{nil}, then @code{kill-new} replaces the
|
|
first element of the kill ring with @var{string}, rather than pushing
|
|
@var{string} onto the kill ring.
|
|
@end defun
|
|
|
|
@defun kill-append string before-p
|
|
This function appends the text @var{string} to the first entry in the
|
|
kill ring and makes the yanking pointer point to the combined entry.
|
|
Normally @var{string} goes at the end of the entry, but if
|
|
@var{before-p} is non-@code{nil}, it goes at the beginning. This
|
|
function calls @code{kill-new} as a subroutine, thus causing the
|
|
values of @code{interprogram-cut-function} and possibly
|
|
@code{interprogram-paste-function} (see below) to be invoked by
|
|
extension.
|
|
@end defun
|
|
|
|
@defvar interprogram-paste-function
|
|
This variable provides a way of transferring killed text from other
|
|
programs, when you are using a window system. Its value should be
|
|
@code{nil} or a function of no arguments.
|
|
|
|
If the value is a function, @code{current-kill} calls it to get the
|
|
most recent kill. If the function returns a non-@code{nil} value,
|
|
then that value is used as the most recent kill. If it returns
|
|
@code{nil}, then the front of the kill ring is used.
|
|
|
|
To facilitate support for window systems that support multiple
|
|
selections, this function may also return a list of strings. In that
|
|
case, the first string is used as the most recent kill, and all
|
|
the other strings are pushed onto the kill ring, for easy access by
|
|
@code{yank-pop}.
|
|
|
|
The normal use of this function is to get the window system's
|
|
clipboard as the most recent kill, even if the selection belongs to
|
|
another application. @xref{Window System Selections}. However, if
|
|
the clipboard contents come from the current Emacs session, this
|
|
function should return @code{nil}.
|
|
@end defvar
|
|
|
|
@defvar interprogram-cut-function
|
|
This variable provides a way of communicating killed text to other
|
|
programs, when you are using a window system. Its value should be
|
|
@code{nil} or a function of one required argument.
|
|
|
|
If the value is a function, @code{kill-new} and @code{kill-append} call
|
|
it with the new first element of the kill ring as the argument.
|
|
|
|
The normal use of this function is to put newly killed text in the
|
|
window system's clipboard. @xref{Window System Selections}.
|
|
@end defvar
|
|
|
|
@node Internals of Kill Ring
|
|
@subsection Internals of the Kill Ring
|
|
|
|
The variable @code{kill-ring} holds the kill ring contents, in the
|
|
form of a list of strings. The most recent kill is always at the front
|
|
of the list.
|
|
|
|
The @code{kill-ring-yank-pointer} variable points to a link in the
|
|
kill ring list, whose @sc{car} is the text to yank next. We say it
|
|
identifies the front of the ring. Moving
|
|
@code{kill-ring-yank-pointer} to a different link is called
|
|
@dfn{rotating the kill ring}. We call the kill ring a ``ring'' because
|
|
the functions that move the yank pointer wrap around from the end of the
|
|
list to the beginning, or vice-versa. Rotation of the kill ring is
|
|
virtual; it does not change the value of @code{kill-ring}.
|
|
|
|
Both @code{kill-ring} and @code{kill-ring-yank-pointer} are Lisp
|
|
variables whose values are normally lists. The word ``pointer'' in the
|
|
name of the @code{kill-ring-yank-pointer} indicates that the variable's
|
|
purpose is to identify one element of the list for use by the next yank
|
|
command.
|
|
|
|
The value of @code{kill-ring-yank-pointer} is always @code{eq} to one
|
|
of the links in the kill ring list. The element it identifies is the
|
|
@sc{car} of that link. Kill commands, which change the kill ring, also
|
|
set this variable to the value of @code{kill-ring}. The effect is to
|
|
rotate the ring so that the newly killed text is at the front.
|
|
|
|
Here is a diagram that shows the variable @code{kill-ring-yank-pointer}
|
|
pointing to the second entry in the kill ring @code{("some text" "a
|
|
different piece of text" "yet older text")}.
|
|
|
|
@example
|
|
@group
|
|
kill-ring ---- kill-ring-yank-pointer
|
|
| |
|
|
| v
|
|
| --- --- --- --- --- ---
|
|
--> | | |------> | | |--> | | |--> nil
|
|
--- --- --- --- --- ---
|
|
| | |
|
|
| | |
|
|
| | -->"yet older text"
|
|
| |
|
|
| --> "a different piece of text"
|
|
|
|
|
--> "some text"
|
|
@end group
|
|
@end example
|
|
|
|
@noindent
|
|
This state of affairs might occur after @kbd{C-y} (@code{yank})
|
|
immediately followed by @kbd{M-y} (@code{yank-pop}).
|
|
|
|
@defvar kill-ring
|
|
This variable holds the list of killed text sequences, most recently
|
|
killed first.
|
|
@end defvar
|
|
|
|
@defvar kill-ring-yank-pointer
|
|
This variable's value indicates which element of the kill ring is at the
|
|
front of the ring for yanking. More precisely, the value is a tail
|
|
of the value of @code{kill-ring}, and its @sc{car} is the kill string
|
|
that @kbd{C-y} should yank.
|
|
@end defvar
|
|
|
|
@defopt kill-ring-max
|
|
The value of this variable is the maximum length to which the kill
|
|
ring can grow, before elements are thrown away at the end. The default
|
|
value for @code{kill-ring-max} is 120.
|
|
@end defopt
|
|
|
|
@node Undo
|
|
@section Undo
|
|
@cindex redo
|
|
|
|
Most buffers have an @dfn{undo list}, which records all changes made
|
|
to the buffer's text so that they can be undone. (The buffers that
|
|
don't have one are usually special-purpose buffers for which Emacs
|
|
assumes that undoing is not useful. In particular, any buffer whose
|
|
name begins with a space has its undo recording off by default;
|
|
see @ref{Buffer Names}.) All the primitives that modify the
|
|
text in the buffer automatically add elements to the front of the undo
|
|
list, which is in the variable @code{buffer-undo-list}.
|
|
|
|
@defvar buffer-undo-list
|
|
This buffer-local variable's value is the undo list of the current
|
|
buffer. A value of @code{t} disables the recording of undo information.
|
|
@end defvar
|
|
|
|
Here are the kinds of elements an undo list can have:
|
|
|
|
@table @code
|
|
@item @var{position}
|
|
This kind of element records a previous value of point; undoing this
|
|
element moves point to @var{position}. Ordinary cursor motion does not
|
|
make any sort of undo record, but deletion operations use these entries
|
|
to record where point was before the command.
|
|
|
|
@item (@var{beg} . @var{end})
|
|
This kind of element indicates how to delete text that was inserted.
|
|
Upon insertion, the text occupied the range @var{beg}--@var{end} in the
|
|
buffer.
|
|
|
|
@item (@var{text} . @var{position})
|
|
This kind of element indicates how to reinsert text that was deleted.
|
|
The deleted text itself is the string @var{text}. The place to
|
|
reinsert it is @code{(abs @var{position})}. If @var{position} is
|
|
positive, point was at the beginning of the deleted text, otherwise it
|
|
was at the end. Zero or more (@var{marker} . @var{adjustment})
|
|
elements follow immediately after this element.
|
|
|
|
@item (t . @var{time-flag})
|
|
This kind of element indicates that an unmodified buffer became
|
|
modified. A @var{time-flag} that is a non-integer Lisp timestamp
|
|
represents the visited file's modification time as of
|
|
when it was previously visited or saved, using the same format as
|
|
@code{current-time}; see @ref{Time of Day}.
|
|
A @var{time-flag} of 0 means the buffer does not correspond to any file;
|
|
@minus{}1 means the visited file previously did not exist.
|
|
@code{primitive-undo} uses these
|
|
values to determine whether to mark the buffer as unmodified once again;
|
|
it does so only if the file's status matches that of @var{time-flag}.
|
|
|
|
@item (nil @var{property} @var{value} @var{beg} . @var{end})
|
|
This kind of element records a change in a text property.
|
|
Here's how you might undo the change:
|
|
|
|
@example
|
|
(put-text-property @var{beg} @var{end} @var{property} @var{value})
|
|
@end example
|
|
|
|
@item (@var{marker} . @var{adjustment})
|
|
This kind of element records the fact that the marker @var{marker} was
|
|
relocated due to deletion of surrounding text, and that it moved
|
|
@var{adjustment} character positions. If the marker's location is
|
|
consistent with the (@var{text} . @var{position}) element preceding it
|
|
in the undo list, then undoing this element moves @var{marker}
|
|
@minus{} @var{adjustment} characters.
|
|
|
|
@item (apply @var{funname} . @var{args})
|
|
This is an extensible undo item, which is undone by calling
|
|
@var{funname} with arguments @var{args}.
|
|
|
|
@item (apply @var{delta} @var{beg} @var{end} @var{funname} . @var{args})
|
|
This is an extensible undo item, which records a change limited to the
|
|
range @var{beg} to @var{end}, which increased the size of the buffer
|
|
by @var{delta} characters. It is undone by calling @var{funname} with
|
|
arguments @var{args}.
|
|
|
|
This kind of element enables undo limited to a region to determine
|
|
whether the element pertains to that region.
|
|
|
|
@item nil
|
|
This element is a boundary. The elements between two boundaries are
|
|
called a @dfn{change group}; normally, each change group corresponds to
|
|
one keyboard command, and undo commands normally undo an entire group as
|
|
a unit.
|
|
@end table
|
|
|
|
@defun undo-boundary
|
|
This function places a boundary element in the undo list. The undo
|
|
command stops at such a boundary, and successive undo commands undo
|
|
to earlier and earlier boundaries. This function returns @code{nil}.
|
|
|
|
Calling this function explicitly is useful for splitting the effects of
|
|
a command into more than one unit. For example, @code{query-replace}
|
|
calls @code{undo-boundary} after each replacement, so that the user can
|
|
undo individual replacements one by one.
|
|
|
|
Mostly, however, this function is called automatically at an
|
|
appropriate time.
|
|
@end defun
|
|
|
|
@defun undo-auto-amalgamate
|
|
@cindex amalgamating commands, and undo
|
|
@vindex amalgamating-undo-limit
|
|
The editor command loop automatically calls @code{undo-boundary} just
|
|
before executing each key sequence, so that each undo normally undoes
|
|
the effects of one command. A few exceptional commands are
|
|
@dfn{amalgamating}: these commands generally cause small changes to
|
|
buffers, so with these a boundary is inserted only every 20th command,
|
|
allowing the changes to be undone as a group. By default, the commands
|
|
@code{self-insert-command}, which produces self-inserting input
|
|
characters (@pxref{Commands for Insertion}), and @code{delete-char},
|
|
which deletes characters (@pxref{Deletion}), are amalgamating.
|
|
Where a command affects the contents of several buffers, as may happen,
|
|
for example, when a function on the @code{post-command-hook} affects a
|
|
buffer other than the @code{current-buffer}, then @code{undo-boundary}
|
|
will be called in each of the affected buffers.
|
|
|
|
This function can be called before an amalgamating command. It
|
|
removes the previous @code{undo-boundary} if a series of such calls
|
|
have been made.
|
|
|
|
The maximum number of changes that can be amalgamated is controlled by
|
|
the @code{amalgamating-undo-limit} variable. If this variable is 1,
|
|
no changes are amalgamated.
|
|
@end defun
|
|
|
|
A Lisp program can amalgamate a series of changes into a single change
|
|
group by calling @code{undo-amalgamate-change-group} (@pxref{Atomic
|
|
Changes}). Note that @code{amalgamating-undo-limit} has no effect on
|
|
the groups produced by that function.
|
|
|
|
@defvar undo-auto-current-boundary-timer
|
|
Some buffers, such as process buffers, can change even when no
|
|
commands are executing. In these cases, @code{undo-boundary} is
|
|
normally called periodically by the timer in this variable. Setting
|
|
this variable to non-@code{nil} prevents this behavior.
|
|
@end defvar
|
|
|
|
@defvar undo-in-progress
|
|
This variable is normally @code{nil}, but the undo commands bind it to
|
|
@code{t}. This is so that various kinds of change hooks can tell when
|
|
they're being called for the sake of undoing.
|
|
@end defvar
|
|
|
|
@defun primitive-undo count list
|
|
This is the basic function for undoing elements of an undo list.
|
|
It undoes the first @var{count} elements of @var{list}, returning
|
|
the rest of @var{list}.
|
|
|
|
@code{primitive-undo} adds elements to the buffer's undo list when it
|
|
changes the buffer. Undo commands avoid confusion by saving the undo
|
|
list value at the beginning of a sequence of undo operations. Then the
|
|
undo operations use and update the saved value. The new elements added
|
|
by undoing are not part of this saved value, so they don't interfere with
|
|
continuing to undo.
|
|
|
|
This function does not bind @code{undo-in-progress}.
|
|
@end defun
|
|
|
|
@defmac with-undo-amalgamate body@dots{}
|
|
This macro removes all the undo boundaries inserted during the
|
|
execution of @var{body} so that it can be undone as a single step.
|
|
@end defmac
|
|
|
|
Some commands leave the region active after execution in such a way that
|
|
it interferes with selective undo of that command. To make @code{undo}
|
|
ignore the active region when invoked immediately after such a command,
|
|
set the property @code{undo-inhibit-region} of the command's function
|
|
symbol to a non-@code{nil} value. @xref{Standard Properties}.
|
|
|
|
@node Maintaining Undo
|
|
@section Maintaining Undo Lists
|
|
|
|
This section describes how to enable and disable undo information for
|
|
a given buffer. It also explains how the undo list is truncated
|
|
automatically so it doesn't get too big.
|
|
|
|
Recording of undo information in a newly created buffer is normally
|
|
enabled to start with; but if the buffer name starts with a space, the
|
|
undo recording is initially disabled. You can explicitly enable or
|
|
disable undo recording with the following two functions, or by setting
|
|
@code{buffer-undo-list} yourself.
|
|
|
|
@deffn Command buffer-enable-undo &optional buffer-or-name
|
|
This command enables recording undo information for buffer
|
|
@var{buffer-or-name}, so that subsequent changes can be undone. If no
|
|
argument is supplied, then the current buffer is used. This function
|
|
does nothing if undo recording is already enabled in the buffer. It
|
|
returns @code{nil}.
|
|
|
|
In an interactive call, @var{buffer-or-name} is the current buffer.
|
|
You cannot specify any other buffer.
|
|
@end deffn
|
|
|
|
@deffn Command buffer-disable-undo &optional buffer-or-name
|
|
@cindex disabling undo
|
|
This function discards the undo list of @var{buffer-or-name}, and disables
|
|
further recording of undo information. As a result, it is no longer
|
|
possible to undo either previous changes or any subsequent changes. If
|
|
the undo list of @var{buffer-or-name} is already disabled, this function
|
|
has no effect.
|
|
|
|
In an interactive call, BUFFER-OR-NAME is the current buffer. You
|
|
cannot specify any other buffer. This function returns @code{nil}.
|
|
@end deffn
|
|
|
|
As editing continues, undo lists get longer and longer. To prevent
|
|
them from using up all available memory space, garbage collection trims
|
|
them back to size limits you can set. (For this purpose, the size
|
|
of an undo list measures the cons cells that make up the list, plus the
|
|
strings of deleted text.) Three variables control the range of acceptable
|
|
sizes: @code{undo-limit}, @code{undo-strong-limit} and
|
|
@code{undo-outer-limit}. In these variables, size is counted as the
|
|
number of bytes occupied, which includes both saved text and other
|
|
data.
|
|
|
|
@defopt undo-limit
|
|
This is the soft limit for the acceptable size of an undo list. The
|
|
change group at which this size is exceeded is the last one kept.
|
|
@end defopt
|
|
|
|
@defopt undo-strong-limit
|
|
This is the upper limit for the acceptable size of an undo list. The
|
|
change group at which this size is exceeded is discarded itself (along
|
|
with all older change groups). There is one exception: the very latest
|
|
change group is only discarded if it exceeds @code{undo-outer-limit}.
|
|
@end defopt
|
|
|
|
@defopt undo-outer-limit
|
|
If at garbage collection time the undo info for the current command
|
|
exceeds this limit, Emacs discards the info and displays a warning.
|
|
This is a last ditch limit to prevent memory overflow.
|
|
@end defopt
|
|
|
|
@defopt undo-ask-before-discard
|
|
If this variable is non-@code{nil}, when the undo info exceeds
|
|
@code{undo-outer-limit}, Emacs asks in the echo area whether to
|
|
discard the info. The default value is @code{nil}, which means to
|
|
discard it automatically.
|
|
|
|
This option is mainly intended for debugging. Garbage collection is
|
|
inhibited while the question is asked, which means that Emacs might
|
|
leak memory if the user waits too long before answering the question.
|
|
@end defopt
|
|
|
|
@node Filling
|
|
@section Filling
|
|
@cindex filling text
|
|
|
|
@dfn{Filling} means adjusting the lengths of lines (by moving the line
|
|
breaks) so that they are nearly (but no greater than) a specified
|
|
maximum width. Additionally, lines can be @dfn{justified}, which means
|
|
inserting spaces to make the left and/or right margins line up
|
|
precisely. The width is controlled by the variable @code{fill-column}.
|
|
For ease of reading, lines should be no longer than 70 or so columns.
|
|
|
|
You can use Auto Fill mode (@pxref{Auto Filling}) to fill text
|
|
automatically as you insert it, but changes to existing text may leave
|
|
it improperly filled. Then you must fill the text explicitly.
|
|
|
|
Most of the commands in this section return values that are not
|
|
meaningful. All the functions that do filling take note of the current
|
|
left margin, current right margin, and current justification style
|
|
(@pxref{Margins}). If the current justification style is
|
|
@code{none}, the filling functions don't actually do anything.
|
|
|
|
Several of the filling functions have an argument @var{justify}.
|
|
If it is non-@code{nil}, that requests some kind of justification. It
|
|
can be @code{left}, @code{right}, @code{full}, or @code{center}, to
|
|
request a specific style of justification. If it is @code{t}, that
|
|
means to use the current justification style for this part of the text
|
|
(see @code{current-justification}, below). Any other value is treated
|
|
as @code{full}.
|
|
|
|
When you call the filling functions interactively, using a prefix
|
|
argument implies the value @code{full} for @var{justify}.
|
|
|
|
@deffn Command fill-paragraph &optional justify region
|
|
This command fills the paragraph at or after point. If
|
|
@var{justify} is non-@code{nil}, each line is justified as well.
|
|
It uses the ordinary paragraph motion commands to find paragraph
|
|
boundaries. @xref{Paragraphs,,, emacs, The GNU Emacs Manual}.
|
|
|
|
When @var{region} is non-@code{nil}, then if Transient Mark mode is
|
|
enabled and the mark is active, this command calls @code{fill-region}
|
|
to fill all the paragraphs in the region, instead of filling only the
|
|
current paragraph. When this command is called interactively,
|
|
@var{region} is @code{t}.
|
|
@end deffn
|
|
|
|
@deffn Command fill-region start end &optional justify nosqueeze to-eop
|
|
This command fills each of the paragraphs in the region from @var{start}
|
|
to @var{end}. It justifies as well if @var{justify} is
|
|
non-@code{nil}.
|
|
|
|
If @var{nosqueeze} is non-@code{nil}, that means to leave whitespace
|
|
other than line breaks untouched. If @var{to-eop} is non-@code{nil},
|
|
that means to keep filling to the end of the paragraph---or the next hard
|
|
newline, if @code{use-hard-newlines} is enabled (see below).
|
|
|
|
The variable @code{paragraph-separate} controls how to distinguish
|
|
paragraphs. @xref{Standard Regexps}.
|
|
@end deffn
|
|
|
|
@defun pixel-fill-region start end pixel-width
|
|
Most Emacs buffers use monospaced text, so all the filling functions
|
|
(like @code{fill-region}) work based on the number of characters and
|
|
@code{char-width}. However, Emacs can render other types of things,
|
|
like text that contains images and using proportional fonts, and the
|
|
@code{pixel-fill-region} exists to handle that. It fills the region
|
|
of text between @var{start} and @var{end} at pixel granularity, so
|
|
text using variable-pitch fonts or several different fonts looks
|
|
filled regardless of different character sizes. The argument
|
|
@var{pixel-width} specifies the maximum pixel width a line is allowed
|
|
to have after filling; it is the pixel-resolution equivalent of the
|
|
@code{fill-column} in @code{fill-region}. For instance, this Lisp
|
|
snippet will insert text using a proportional font, and then fill this
|
|
to be no wider than 300 pixels:
|
|
|
|
@lisp
|
|
(insert (propertize
|
|
"This is a sentence that's ends here."
|
|
'face 'variable-pitch))
|
|
(pixel-fill-region (point) (point-max) 300)
|
|
@end lisp
|
|
|
|
If @var{start} isn't at the start of a line, the horizontal position
|
|
of @var{start}, converted to pixel units, will be used as the
|
|
indentation prefix on subsequent lines.
|
|
|
|
@findex pixel-fill-width
|
|
The @code{pixel-fill-width} helper function can be used to compute the
|
|
pixel width to use. If given no arguments, it'll return a value
|
|
slightly less than the width of the current window. The first
|
|
optional value, @var{columns}, specifies the number of columns using
|
|
the standard, monospaced fonts, e.g. @code{fill-column}. The second
|
|
optional value is the window to use. You'd typically use it like
|
|
this:
|
|
|
|
@lisp
|
|
(pixel-fill-region
|
|
start end (pixel-fill-width fill-column))
|
|
@end lisp
|
|
@end defun
|
|
|
|
@deffn Command fill-individual-paragraphs start end &optional justify citation-regexp
|
|
This command fills each paragraph in the region according to its
|
|
individual fill prefix. Thus, if the lines of a paragraph were indented
|
|
with spaces, the filled paragraph will remain indented in the same
|
|
fashion.
|
|
|
|
The first two arguments, @var{start} and @var{end}, are the beginning
|
|
and end of the region to be filled. The third and fourth arguments,
|
|
@var{justify} and @var{citation-regexp}, are optional. If
|
|
@var{justify} is non-@code{nil}, the paragraphs are justified as
|
|
well as filled. If @var{citation-regexp} is non-@code{nil}, it means the
|
|
function is operating on a mail message and therefore should not fill
|
|
the header lines. If @var{citation-regexp} is a string, it is used as
|
|
a regular expression; if it matches the beginning of a line, that line
|
|
is treated as a citation marker.
|
|
|
|
@c FIXME: "That mode" is confusing. It isn't a major/minor mode.
|
|
Ordinarily, @code{fill-individual-paragraphs} regards each change in
|
|
indentation as starting a new paragraph. If
|
|
@code{fill-individual-varying-indent} is non-@code{nil}, then only
|
|
separator lines separate paragraphs. That mode can handle indented
|
|
paragraphs with additional indentation on the first line.
|
|
@end deffn
|
|
|
|
@defopt fill-individual-varying-indent
|
|
This variable alters the action of @code{fill-individual-paragraphs} as
|
|
described above.
|
|
@end defopt
|
|
|
|
@deffn Command fill-region-as-paragraph start end &optional justify nosqueeze squeeze-after
|
|
This command considers a region of text as a single paragraph and fills
|
|
it. If the region was made up of many paragraphs, the blank lines
|
|
between paragraphs are removed. This function justifies as well as
|
|
filling when @var{justify} is non-@code{nil}.
|
|
|
|
If @var{nosqueeze} is non-@code{nil}, that means to leave whitespace
|
|
other than line breaks untouched. If @var{squeeze-after} is
|
|
non-@code{nil}, it specifies a position in the region, and means
|
|
that whitespace other than line breaks should be left untouched before
|
|
that position.
|
|
|
|
In Adaptive Fill mode, this command calls @code{fill-context-prefix} to
|
|
choose a fill prefix by default. @xref{Adaptive Fill}.
|
|
@end deffn
|
|
|
|
@deffn Command justify-current-line &optional how eop nosqueeze
|
|
This command inserts spaces between the words of the current line so
|
|
that the line ends exactly at @code{fill-column}. It returns
|
|
@code{nil}.
|
|
|
|
The argument @var{how}, if non-@code{nil} specifies explicitly the style
|
|
of justification. It can be @code{left}, @code{right}, @code{full},
|
|
@code{center}, or @code{none}. If it is @code{t}, that means to
|
|
follow specified justification style (see @code{current-justification},
|
|
below). @code{nil} means to do full justification.
|
|
|
|
If @var{eop} is non-@code{nil}, that means do only left-justification
|
|
if @code{current-justification} specifies full justification. This is
|
|
used for the last line of a paragraph; even if the paragraph as a
|
|
whole is fully justified, the last line should not be.
|
|
|
|
If @var{nosqueeze} is non-@code{nil}, that means do not change interior
|
|
whitespace.
|
|
@end deffn
|
|
|
|
@defopt default-justification
|
|
This variable's value specifies the style of justification to use for
|
|
text that doesn't specify a style with a text property. The possible
|
|
values are @code{left}, @code{right}, @code{full}, @code{center}, or
|
|
@code{none}. The default value is @code{left}.
|
|
@end defopt
|
|
|
|
@defun current-justification
|
|
This function returns the proper justification style to use for filling
|
|
the text around point.
|
|
|
|
This returns the value of the @code{justification} text property at
|
|
point, or the variable @code{default-justification} if there is no such
|
|
text property. However, it returns @code{nil} rather than @code{none}
|
|
to mean ``don't justify''.
|
|
@end defun
|
|
|
|
@defopt sentence-end-double-space
|
|
@anchor{Definition of sentence-end-double-space}
|
|
If this variable is non-@code{nil}, a period followed by just one space
|
|
does not count as the end of a sentence, and the filling functions
|
|
avoid breaking the line at such a place.
|
|
@end defopt
|
|
|
|
@defopt sentence-end-without-period
|
|
If this variable is non-@code{nil}, a sentence can end without a
|
|
period. This is used for languages like Thai, where sentences end
|
|
with a double space but without a period.
|
|
@end defopt
|
|
|
|
@defopt sentence-end-without-space
|
|
If this variable is non-@code{nil}, it should be a string of
|
|
characters that can end a sentence without following spaces.
|
|
@end defopt
|
|
|
|
@defopt fill-separate-heterogeneous-words-with-space
|
|
If this variable is non-@code{nil}, two words of different kind (e.g.,
|
|
English and CJK) will be separated with a space when concatenating one
|
|
that is in the end of a line and the other that is in the beginning of
|
|
the next line for filling.
|
|
@end defopt
|
|
|
|
@defvar fill-paragraph-function
|
|
This variable provides a way to override the filling of paragraphs.
|
|
If its value is non-@code{nil}, @code{fill-paragraph} calls this
|
|
function to do the work. If the function returns a non-@code{nil}
|
|
value, @code{fill-paragraph} assumes the job is done, and immediately
|
|
returns that value.
|
|
|
|
The usual use of this feature is to fill comments in programming
|
|
language modes. If the function needs to fill a paragraph in the usual
|
|
way, it can do so as follows:
|
|
|
|
@example
|
|
(let ((fill-paragraph-function nil))
|
|
(fill-paragraph arg))
|
|
@end example
|
|
@end defvar
|
|
|
|
@defvar fill-forward-paragraph-function
|
|
This variable provides a way to override how the filling functions,
|
|
such as @code{fill-region} and @code{fill-paragraph}, move forward to
|
|
the next paragraph. Its value should be a function, which is called
|
|
with a single argument @var{n}, the number of paragraphs to move, and
|
|
should return the difference between @var{n} and the number of
|
|
paragraphs actually moved. The default value of this variable is
|
|
@code{forward-paragraph}. @xref{Paragraphs,,, emacs, The GNU Emacs
|
|
Manual}.
|
|
@end defvar
|
|
|
|
@defvar use-hard-newlines
|
|
If this variable is non-@code{nil}, the filling functions do not delete
|
|
newlines that have the @code{hard} text property. These hard
|
|
newlines act as paragraph separators. @xref{Hard and Soft
|
|
Newlines,, Hard and Soft Newlines, emacs, The GNU Emacs Manual}.
|
|
@end defvar
|
|
|
|
@node Margins
|
|
@section Margins for Filling
|
|
@cindex margins, filling
|
|
|
|
@defopt fill-prefix
|
|
This buffer-local variable, if non-@code{nil}, specifies a string of
|
|
text that appears at the beginning of normal text lines and should be
|
|
disregarded when filling them. Any line that fails to start with the
|
|
fill prefix is considered the start of a paragraph; so is any line
|
|
that starts with the fill prefix followed by additional whitespace.
|
|
Lines that start with the fill prefix but no additional whitespace are
|
|
ordinary text lines that can be filled together. The resulting filled
|
|
lines also start with the fill prefix.
|
|
|
|
The fill prefix follows the left margin whitespace, if any.
|
|
@end defopt
|
|
|
|
@defopt fill-column
|
|
This buffer-local variable specifies the maximum width of filled lines.
|
|
Its value should be an integer, which is a number of columns. All the
|
|
filling, justification, and centering commands are affected by this
|
|
variable, including Auto Fill mode (@pxref{Auto Filling}).
|
|
|
|
As a practical matter, if you are writing text for other people to
|
|
read, you should set @code{fill-column} to no more than 70. Otherwise
|
|
the line will be too long for people to read comfortably, and this can
|
|
make the text seem clumsy.
|
|
|
|
The default value for @code{fill-column} is 70. To disable Auto Fill
|
|
mode in a specific mode, you could say something like:
|
|
|
|
@lisp
|
|
(add-hook 'foo-mode-hook (lambda () (auto-fill-mode -1))
|
|
@end lisp
|
|
@end defopt
|
|
|
|
@deffn Command set-left-margin from to margin
|
|
This sets the @code{left-margin} property on the text from @var{from} to
|
|
@var{to} to the value @var{margin}. If Auto Fill mode is enabled, this
|
|
command also refills the region to fit the new margin.
|
|
@end deffn
|
|
|
|
@deffn Command set-right-margin from to margin
|
|
This sets the @code{right-margin} property on the text from @var{from}
|
|
to @var{to} to the value @var{margin}. If Auto Fill mode is enabled,
|
|
this command also refills the region to fit the new margin.
|
|
@end deffn
|
|
|
|
@defun current-left-margin
|
|
This function returns the proper left margin value to use for filling
|
|
the text around point. The value is the sum of the @code{left-margin}
|
|
property of the character at the start of the current line (or zero if
|
|
none), and the value of the variable @code{left-margin}.
|
|
@end defun
|
|
|
|
@defun current-fill-column
|
|
This function returns the proper fill column value to use for filling
|
|
the text around point. The value is the value of the @code{fill-column}
|
|
variable, minus the value of the @code{right-margin} property of the
|
|
character after point.
|
|
@end defun
|
|
|
|
@deffn Command move-to-left-margin &optional n force
|
|
This function moves point to the left margin of the current line. The
|
|
column moved to is determined by calling the function
|
|
@code{current-left-margin}. If the argument @var{n} is non-@code{nil},
|
|
@code{move-to-left-margin} moves forward @var{n}@minus{}1 lines first.
|
|
|
|
If @var{force} is non-@code{nil}, that says to fix the line's
|
|
indentation if that doesn't match the left margin value.
|
|
@end deffn
|
|
|
|
@defun delete-to-left-margin &optional from to
|
|
This function removes left margin indentation from the text between
|
|
@var{from} and @var{to}. The amount of indentation to delete is
|
|
determined by calling @code{current-left-margin}. In no case does this
|
|
function delete non-whitespace. If @var{from} and @var{to} are omitted,
|
|
they default to the whole buffer.
|
|
@end defun
|
|
|
|
@defun indent-to-left-margin
|
|
This function adjusts the indentation at the beginning of the current
|
|
line to the value specified by the variable @code{left-margin}. (That
|
|
may involve either inserting or deleting whitespace.) This function
|
|
is value of @code{indent-line-function} in Paragraph-Indent Text mode.
|
|
@end defun
|
|
|
|
@defopt left-margin
|
|
This variable specifies the base left margin column. In Fundamental
|
|
mode, @key{RET} indents to this column. This variable automatically
|
|
becomes buffer-local when set in any fashion.
|
|
@end defopt
|
|
|
|
@defopt fill-nobreak-predicate
|
|
This variable gives major modes a way to specify not to break a line
|
|
at certain places. Its value should be a list of functions. Whenever
|
|
filling considers breaking the line at a certain place in the buffer,
|
|
it calls each of these functions with no arguments and with point
|
|
located at that place. If any of the functions returns
|
|
non-@code{nil}, then the line won't be broken there.
|
|
@end defopt
|
|
|
|
@node Adaptive Fill
|
|
@section Adaptive Fill Mode
|
|
@c @cindex Adaptive Fill mode "adaptive-fill-mode" is adjacent.
|
|
|
|
When @dfn{Adaptive Fill Mode} is enabled, Emacs determines the fill
|
|
prefix automatically from the text in each paragraph being filled
|
|
rather than using a predetermined value. During filling, this fill
|
|
prefix gets inserted at the start of the second and subsequent lines
|
|
of the paragraph as described in @ref{Filling}, and in @ref{Auto
|
|
Filling}.
|
|
|
|
@defopt adaptive-fill-mode
|
|
Adaptive Fill mode is enabled when this variable is non-@code{nil}.
|
|
It is @code{t} by default.
|
|
@end defopt
|
|
|
|
@defun fill-context-prefix from to
|
|
This function implements the heart of Adaptive Fill mode; it chooses a
|
|
fill prefix based on the text between @var{from} and @var{to},
|
|
typically the start and end of a paragraph. It does this by looking
|
|
at the first two lines of the paragraph, based on the variables
|
|
described below.
|
|
@c The optional argument first-line-regexp is not documented
|
|
@c because it exists for internal purposes and might be eliminated
|
|
@c in the future.
|
|
|
|
Usually, this function returns the fill prefix, a string. However,
|
|
before doing this, the function makes a final check (not specially
|
|
mentioned in the following) that a line starting with this prefix
|
|
wouldn't look like the start of a paragraph. Should this happen, the
|
|
function signals the anomaly by returning @code{nil} instead.
|
|
|
|
In detail, @code{fill-context-prefix} does this:
|
|
|
|
@enumerate
|
|
@item
|
|
It takes a candidate for the fill prefix from the first line---it
|
|
tries first the function in @code{adaptive-fill-function} (if any),
|
|
then the regular expression @code{adaptive-fill-regexp} (see below).
|
|
The first non-@code{nil} result of these, or the empty string if
|
|
they're both @code{nil}, becomes the first line's candidate.
|
|
@item
|
|
If the paragraph has as yet only one line, the function tests the
|
|
validity of the prefix candidate just found. The function then
|
|
returns the candidate if it's valid, or a string of spaces otherwise.
|
|
(see the description of @code{adaptive-fill-first-line-regexp} below).
|
|
@item
|
|
When the paragraph already has two lines, the function next looks for
|
|
a prefix candidate on the second line, in just the same way it did for
|
|
the first line. If it doesn't find one, it returns @code{nil}.
|
|
@item
|
|
The function now compares the two candidate prefixes heuristically: if
|
|
the non-whitespace characters in the line 2 candidate occur in the
|
|
same order in the line 1 candidate, the function returns the line 2
|
|
candidate. Otherwise, it returns the largest initial substring which
|
|
is common to both candidates (which might be the empty string).
|
|
@end enumerate
|
|
@end defun
|
|
|
|
@defopt adaptive-fill-regexp
|
|
Adaptive Fill mode matches this regular expression against the text
|
|
starting after the left margin whitespace (if any) on a line; the
|
|
characters it matches are that line's candidate for the fill prefix.
|
|
|
|
The default value matches whitespace with certain punctuation
|
|
characters intermingled.
|
|
@end defopt
|
|
|
|
@defopt adaptive-fill-first-line-regexp
|
|
Used only in one-line paragraphs, this regular expression acts as an
|
|
additional check of the validity of the one available candidate fill
|
|
prefix: the candidate must match this regular expression, or match
|
|
@code{comment-start-skip}. If it doesn't, @code{fill-context-prefix}
|
|
replaces the candidate with a string of spaces of the same width
|
|
as it.
|
|
|
|
The default value of this variable is @w{@code{"\\`[ \t]*\\'"}}, which
|
|
matches only a string of whitespace. The effect of this default is to
|
|
force the fill prefixes found in one-line paragraphs always to be pure
|
|
whitespace.
|
|
@end defopt
|
|
|
|
@defopt adaptive-fill-function
|
|
You can specify more complex ways of choosing a fill prefix
|
|
automatically by setting this variable to a function. The function is
|
|
called with point after the left margin (if any) of a line, and it
|
|
must preserve point. It should return either that line's fill
|
|
prefix or @code{nil}, meaning it has failed to determine a prefix.
|
|
@end defopt
|
|
|
|
@node Auto Filling
|
|
@section Auto Filling
|
|
@cindex filling, automatic
|
|
@cindex Auto Fill mode
|
|
|
|
Auto Fill mode is a minor mode that fills lines automatically as text is
|
|
inserted. @xref{Auto Fill,,, emacs, The GNU Emacs Manual}. This
|
|
section describes some variables used by Auto Fill mode. For a
|
|
description of functions that you can call explicitly to fill and
|
|
justify existing text, see @ref{Filling}.
|
|
|
|
Auto Fill mode also enables the functions that change the margins and
|
|
justification style to refill portions of the text. @xref{Margins}.
|
|
|
|
@defvar auto-fill-function
|
|
The value of this buffer-local variable should be a function (of no
|
|
arguments) to be called after self-inserting a character from the table
|
|
@code{auto-fill-chars}, see below. It may be @code{nil}, in which case
|
|
nothing special is done in that case.
|
|
|
|
The value of @code{auto-fill-function} is @code{do-auto-fill} when Auto
|
|
Fill mode is enabled. That is a function whose sole purpose is to
|
|
implement the usual strategy for breaking a line.
|
|
@end defvar
|
|
|
|
@defvar normal-auto-fill-function
|
|
This variable specifies the function to use for
|
|
@code{auto-fill-function}, if and when Auto Fill is turned on. Major
|
|
modes can set buffer-local values for this variable to alter how Auto
|
|
Fill works.
|
|
@end defvar
|
|
|
|
@defvar auto-fill-chars
|
|
A char table of characters which invoke @code{auto-fill-function} when
|
|
self-inserted---space and newline in most language environments. They
|
|
have an entry @code{t} in the table.
|
|
@end defvar
|
|
|
|
@defopt comment-auto-fill-only-comments
|
|
This variable, if non-@code{nil}, means to fill lines automatically
|
|
within comments only. More precisely, this means that if a comment
|
|
syntax was defined for the current buffer, then self-inserting a
|
|
character outside of a comment will not call @code{auto-fill-function}.
|
|
@end defopt
|
|
|
|
|
|
@node Sorting
|
|
@section Sorting Text
|
|
@cindex sorting text
|
|
|
|
The sorting functions described in this section all rearrange text in
|
|
a buffer. This is in contrast to the function @code{sort}, which
|
|
rearranges the order of the elements of a list (@pxref{Rearrangement}).
|
|
The values returned by these functions are not meaningful.
|
|
|
|
@defun sort-subr reverse nextrecfun endrecfun &optional startkeyfun endkeyfun predicate
|
|
This function is the general text-sorting routine that subdivides a
|
|
buffer into records and then sorts them. Most of the commands in this
|
|
section use this function.
|
|
|
|
To understand how @code{sort-subr} works, consider the whole accessible
|
|
portion of the buffer as being divided into disjoint pieces called
|
|
@dfn{sort records}. The records may or may not be contiguous, but they
|
|
must not overlap. A portion of each sort record (perhaps all of it) is
|
|
designated as the sort key. Sorting rearranges the records in order by
|
|
their sort keys.
|
|
|
|
Usually, the records are rearranged in order of ascending sort key.
|
|
If the first argument to the @code{sort-subr} function, @var{reverse},
|
|
is non-@code{nil}, the sort records are rearranged in order of
|
|
descending sort key.
|
|
|
|
The next four arguments to @code{sort-subr} are functions that are
|
|
called to move point across a sort record. They are called many times
|
|
from within @code{sort-subr}.
|
|
|
|
@enumerate
|
|
@item
|
|
@var{nextrecfun} is called with point at the end of a record. This
|
|
function moves point to the start of the next record. The first record
|
|
is assumed to start at the position of point when @code{sort-subr} is
|
|
called. Therefore, you should usually move point to the beginning of
|
|
the buffer before calling @code{sort-subr}.
|
|
|
|
This function can indicate there are no more sort records by leaving
|
|
point at the end of the buffer.
|
|
|
|
@item
|
|
@var{endrecfun} is called with point within a record. It moves point to
|
|
the end of the record.
|
|
|
|
@item
|
|
@var{startkeyfun} is called to move point from the start of a record to
|
|
the start of the sort key. This argument is optional; if it is omitted,
|
|
the whole record is the sort key. If supplied, the function should
|
|
either return a non-@code{nil} value to be used as the sort key, or
|
|
return @code{nil} to indicate that the sort key is in the buffer
|
|
starting at point. In the latter case, @var{endkeyfun} is called to
|
|
find the end of the sort key.
|
|
|
|
@item
|
|
@var{endkeyfun} is called to move point from the start of the sort key
|
|
to the end of the sort key. This argument is optional. If
|
|
@var{startkeyfun} returns @code{nil} and this argument is omitted (or
|
|
@code{nil}), then the sort key extends to the end of the record. There
|
|
is no need for @var{endkeyfun} if @var{startkeyfun} returns a
|
|
non-@code{nil} value.
|
|
@end enumerate
|
|
|
|
The argument @var{predicate} is the function to use to compare keys.
|
|
It is called with two arguments, the keys to compare, and should
|
|
return non-@code{nil} if the first key should come before the second
|
|
in the sorting order. What exactly are the key arguments depends on
|
|
what @var{startkeyfun} and @var{endkeyfun} return. If @var{predicate}
|
|
is omitted or @code{nil}, it defaults to @code{<} if the keys are
|
|
numbers, to @code{compare-buffer-substrings} if the keys are cons
|
|
cells (whose @code{car} and @code{cdr} are start and end buffer
|
|
positions of the key), and to @code{string<} otherwise (with keys
|
|
assumed to be strings).
|
|
|
|
As an example of @code{sort-subr}, here is the complete function
|
|
definition for @code{sort-lines}:
|
|
|
|
@example
|
|
@group
|
|
;; @r{Note that the first two lines of doc string}
|
|
;; @r{are effectively one line when viewed by a user.}
|
|
(defun sort-lines (reverse beg end)
|
|
"Sort lines in region alphabetically;\
|
|
argument means descending order.
|
|
Called from a program, there are three arguments:
|
|
@end group
|
|
@group
|
|
REVERSE (non-nil means reverse order),\
|
|
BEG and END (region to sort).
|
|
The variable `sort-fold-case' determines\
|
|
whether alphabetic case affects
|
|
the sort order."
|
|
@end group
|
|
@group
|
|
(interactive "P\nr")
|
|
(save-excursion
|
|
(save-restriction
|
|
(narrow-to-region beg end)
|
|
(goto-char (point-min))
|
|
(let ((inhibit-field-text-motion t))
|
|
(sort-subr reverse 'forward-line 'end-of-line)))))
|
|
@end group
|
|
@end example
|
|
|
|
Here @code{forward-line} moves point to the start of the next record,
|
|
and @code{end-of-line} moves point to the end of record. We do not pass
|
|
the arguments @var{startkeyfun} and @var{endkeyfun}, because the entire
|
|
record is used as the sort key.
|
|
|
|
The @code{sort-paragraphs} function is very much the same, except that
|
|
its @code{sort-subr} call looks like this:
|
|
|
|
@example
|
|
@group
|
|
(sort-subr reverse
|
|
(lambda ()
|
|
(while (and (not (eobp))
|
|
(looking-at paragraph-separate))
|
|
(forward-line 1)))
|
|
'forward-paragraph)
|
|
@end group
|
|
@end example
|
|
|
|
Markers pointing into any sort records are left with no useful
|
|
position after @code{sort-subr} returns.
|
|
@end defun
|
|
|
|
@defopt sort-fold-case
|
|
If this variable is non-@code{nil}, @code{sort-subr} and the other
|
|
buffer sorting functions ignore case when comparing strings.
|
|
@end defopt
|
|
|
|
@deffn Command sort-regexp-fields reverse record-regexp key-regexp start end
|
|
This command sorts the region between @var{start} and @var{end}
|
|
alphabetically as specified by @var{record-regexp} and @var{key-regexp}.
|
|
If @var{reverse} is a negative integer, then sorting is in reverse
|
|
order.
|
|
|
|
Alphabetical sorting means that two sort keys are compared by
|
|
comparing the first characters of each, the second characters of each,
|
|
and so on. If a mismatch is found, it means that the sort keys are
|
|
unequal; the sort key whose character is less at the point of first
|
|
mismatch is the lesser sort key. The individual characters are compared
|
|
according to their numerical character codes in the Emacs character set.
|
|
|
|
The value of the @var{record-regexp} argument specifies how to divide
|
|
the buffer into sort records. At the end of each record, a search is
|
|
done for this regular expression, and the text that matches it is taken
|
|
as the next record. For example, the regular expression @samp{^.+$},
|
|
which matches lines with at least one character besides a newline, would
|
|
make each such line into a sort record. @xref{Regular Expressions}, for
|
|
a description of the syntax and meaning of regular expressions.
|
|
|
|
The value of the @var{key-regexp} argument specifies what part of each
|
|
record is the sort key. The @var{key-regexp} could match the whole
|
|
record, or only a part. In the latter case, the rest of the record has
|
|
no effect on the sorted order of records, but it is carried along when
|
|
the record moves to its new position.
|
|
|
|
The @var{key-regexp} argument can refer to the text matched by a
|
|
subexpression of @var{record-regexp}, or it can be a regular expression
|
|
on its own.
|
|
|
|
If @var{key-regexp} is:
|
|
|
|
@table @asis
|
|
@item @samp{\@var{digit}}
|
|
then the text matched by the @var{digit}th @samp{\(...\)} parenthesis
|
|
grouping in @var{record-regexp} is the sort key.
|
|
|
|
@item @samp{\&}
|
|
then the whole record is the sort key.
|
|
|
|
@item a regular expression
|
|
then @code{sort-regexp-fields} searches for a match for the regular
|
|
expression within the record. If such a match is found, it is the sort
|
|
key. If there is no match for @var{key-regexp} within a record then
|
|
that record is ignored, which means its position in the buffer is not
|
|
changed. (The other records may move around it.)
|
|
@end table
|
|
|
|
For example, if you plan to sort all the lines in the region by the
|
|
first word on each line starting with the letter @samp{f}, you should
|
|
set @var{record-regexp} to @samp{^.*$} and set @var{key-regexp} to
|
|
@samp{\<f\w*\>}. The resulting expression looks like this:
|
|
|
|
@example
|
|
@group
|
|
(sort-regexp-fields nil "^.*$" "\\<f\\w*\\>"
|
|
(region-beginning)
|
|
(region-end))
|
|
@end group
|
|
@end example
|
|
|
|
If you call @code{sort-regexp-fields} interactively, it prompts for
|
|
@var{record-regexp} and @var{key-regexp} in the minibuffer.
|
|
@end deffn
|
|
|
|
@deffn Command sort-lines reverse start end
|
|
This command alphabetically sorts lines in the region between
|
|
@var{start} and @var{end}. If @var{reverse} is non-@code{nil}, the sort
|
|
is in reverse order.
|
|
@end deffn
|
|
|
|
@deffn Command sort-paragraphs reverse start end
|
|
This command alphabetically sorts paragraphs in the region between
|
|
@var{start} and @var{end}. If @var{reverse} is non-@code{nil}, the sort
|
|
is in reverse order.
|
|
@end deffn
|
|
|
|
@deffn Command sort-pages reverse start end
|
|
This command alphabetically sorts pages in the region between
|
|
@var{start} and @var{end}. If @var{reverse} is non-@code{nil}, the sort
|
|
is in reverse order.
|
|
@end deffn
|
|
|
|
@deffn Command sort-fields field start end
|
|
This command sorts lines in the region between @var{start} and
|
|
@var{end}, comparing them alphabetically by the @var{field}th field
|
|
of each line. Fields are separated by whitespace and numbered starting
|
|
from 1. If @var{field} is negative, sorting is by the
|
|
@w{@minus{}@var{field}th} field from the end of the line. This command
|
|
is useful for sorting tables.
|
|
@end deffn
|
|
|
|
@deffn Command sort-numeric-fields field start end
|
|
This command sorts lines in the region between @var{start} and
|
|
@var{end}, comparing them numerically by the @var{field}th field of
|
|
each line. Fields are separated by whitespace and numbered starting
|
|
from 1. The specified field must contain a number in each line of the
|
|
region. Numbers starting with 0 are treated as octal, and numbers
|
|
starting with @samp{0x} are treated as hexadecimal.
|
|
|
|
If @var{field} is negative, sorting is by the
|
|
@w{@minus{}@var{field}th} field from the end of the line. This
|
|
command is useful for sorting tables.
|
|
@end deffn
|
|
|
|
@defopt sort-numeric-base
|
|
This variable specifies the default radix for
|
|
@code{sort-numeric-fields} to parse numbers.
|
|
@end defopt
|
|
|
|
@deffn Command sort-columns reverse &optional beg end
|
|
This command sorts the lines in the region between @var{beg} and
|
|
@var{end}, comparing them alphabetically by a certain range of
|
|
columns. The column positions of @var{beg} and @var{end} bound the
|
|
range of columns to sort on.
|
|
|
|
If @var{reverse} is non-@code{nil}, the sort is in reverse order.
|
|
|
|
One unusual thing about this command is that the entire line
|
|
containing position @var{beg}, and the entire line containing position
|
|
@var{end}, are included in the region sorted.
|
|
|
|
Note that @code{sort-columns} rejects text that contains tabs, because
|
|
tabs could be split across the specified columns. Use @kbd{M-x
|
|
untabify} to convert tabs to spaces before sorting.
|
|
|
|
When possible, this command actually works by calling the @code{sort}
|
|
utility program.
|
|
@end deffn
|
|
|
|
@node Columns
|
|
@section Counting Columns
|
|
@cindex columns
|
|
@cindex counting columns
|
|
@cindex horizontal position
|
|
|
|
The column functions convert between a character position (counting
|
|
characters from the beginning of the buffer) and a column position
|
|
(counting screen characters from the beginning of a line).
|
|
|
|
These functions count each character according to the number of
|
|
columns it occupies on the screen. This means control characters count
|
|
as occupying 2 or 4 columns, depending upon the value of
|
|
@code{ctl-arrow}, and tabs count as occupying a number of columns that
|
|
depends on the value of @code{tab-width} and on the column where the tab
|
|
begins. @xref{Usual Display}.
|
|
|
|
Column number computations ignore the width of the window and the
|
|
amount of horizontal scrolling. Consequently, a column value can be
|
|
arbitrarily high. The first (or leftmost) column is numbered 0. They
|
|
also ignore overlays and text properties, aside from invisibility.
|
|
Invisible text is considered as having zero width, unless
|
|
@code{buffer-invisibility-spec} specifies that invisible text should
|
|
be displayed as ellipsis (@pxref{Invisible Text}).
|
|
|
|
@defun current-column
|
|
This function returns the horizontal position of point, measured in
|
|
columns, counting from 0 at the left margin. The column position is the
|
|
sum of the widths of all the displayed representations of the characters
|
|
between the start of the current line and point.
|
|
@end defun
|
|
|
|
@deffn Command move-to-column column &optional force
|
|
This function moves point to @var{column} in the current line. The
|
|
calculation of @var{column} takes into account the widths of the
|
|
displayed representations of the characters between the start of the
|
|
line and point.
|
|
|
|
When called interactively, @var{column} is the value of prefix numeric
|
|
argument. If @var{column} is not an integer, an error is signaled.
|
|
|
|
@c This behavior used to be documented until 2013/08.
|
|
@ignore
|
|
If column @var{column} is beyond the end of the line, point moves to
|
|
the end of the line. If @var{column} is negative, point moves to the
|
|
beginning of the line.
|
|
@end ignore
|
|
|
|
If it is impossible to move to column @var{column} because that is in
|
|
the middle of a multicolumn character such as a tab, point moves to the
|
|
end of that character. However, if @var{force} is non-@code{nil}, and
|
|
@var{column} is in the middle of a tab, then @code{move-to-column}
|
|
either converts the tab into spaces (when @code{indent-tabs-mode} is
|
|
@code{nil}), or inserts enough spaces before it (otherwise), so that
|
|
point can move precisely to column @var{column}. Other multicolumn
|
|
characters can cause anomalies despite @var{force}, since there is no
|
|
way to split them.
|
|
|
|
The argument @var{force} also has an effect if the line isn't long
|
|
enough to reach column @var{column}; if it is @code{t}, that means to
|
|
add whitespace at the end of the line to reach that column.
|
|
|
|
The return value is the column number actually moved to.
|
|
@end deffn
|
|
|
|
@node Indentation
|
|
@section Indentation
|
|
@cindex indentation
|
|
|
|
The indentation functions are used to examine, move to, and change
|
|
whitespace that is at the beginning of a line. Some of the functions
|
|
can also change whitespace elsewhere on a line. Columns and indentation
|
|
count from zero at the left margin.
|
|
|
|
@menu
|
|
* Primitive Indent:: Functions used to count and insert indentation.
|
|
* Mode-Specific Indent:: Customize indentation for different modes.
|
|
* Region Indent:: Indent all the lines in a region.
|
|
* Relative Indent:: Indent the current line based on previous lines.
|
|
* Indent Tabs:: Adjustable, typewriter-like tab stops.
|
|
* Motion by Indent:: Move to first non-blank character.
|
|
@end menu
|
|
|
|
@node Primitive Indent
|
|
@subsection Indentation Primitives
|
|
|
|
This section describes the primitive functions used to count and
|
|
insert indentation. The functions in the following sections use these
|
|
primitives. @xref{Size of Displayed Text}, for related functions.
|
|
|
|
@defun current-indentation
|
|
@comment !!Type Primitive Function
|
|
@comment !!SourceFile indent.c
|
|
This function returns the indentation of the current line, which is
|
|
the horizontal position of the first nonblank character. If the
|
|
contents are entirely blank, then this is the horizontal position of the
|
|
end of the line.
|
|
|
|
This function considers invisible text as having zero width, unless
|
|
@code{buffer-invisibility-spec} specifies that invisible text should
|
|
be displayed as ellipsis. @xref{Invisible Text}.
|
|
@end defun
|
|
|
|
@deffn Command indent-to column &optional minimum
|
|
@comment !!Type Primitive Function
|
|
@comment !!SourceFile indent.c
|
|
This function indents from point with tabs and spaces until @var{column}
|
|
is reached. If @var{minimum} is specified and non-@code{nil}, then at
|
|
least that many spaces are inserted even if this requires going beyond
|
|
@var{column}. Otherwise the function does nothing if point is already
|
|
beyond @var{column}. The value is the column at which the inserted
|
|
indentation ends.
|
|
|
|
The inserted whitespace characters inherit text properties from the
|
|
surrounding text (usually, from the preceding text only). @xref{Sticky
|
|
Properties}.
|
|
@end deffn
|
|
|
|
@defopt indent-tabs-mode
|
|
@comment !!SourceFile indent.c
|
|
If this variable is non-@code{nil}, indentation functions can insert
|
|
tabs as well as spaces. Otherwise, they insert only spaces. Setting
|
|
this variable automatically makes it buffer-local in the current buffer.
|
|
@end defopt
|
|
|
|
@node Mode-Specific Indent
|
|
@subsection Indentation Controlled by Major Mode
|
|
|
|
An important function of each major mode is to customize the @key{TAB}
|
|
key to indent properly for the language being edited. This section
|
|
describes the mechanism of the @key{TAB} key and how to control it.
|
|
The functions in this section return unpredictable values.
|
|
|
|
@deffn Command indent-for-tab-command &optional rigid
|
|
This is the command bound to @key{TAB} in most editing modes. Its
|
|
usual action is to indent the current line, but it can alternatively
|
|
insert a tab character or indent a region.
|
|
|
|
Here is what it does:
|
|
|
|
@itemize
|
|
@item
|
|
First, it checks whether Transient Mark mode is enabled and the region
|
|
is active. If so, it calls @code{indent-region} to indent all the
|
|
text in the region (@pxref{Region Indent}).
|
|
|
|
@item
|
|
Otherwise, if the indentation function in @code{indent-line-function}
|
|
is @code{indent-to-left-margin} (a trivial command that inserts a tab
|
|
character), or if the variable @code{tab-always-indent} specifies that
|
|
a tab character ought to be inserted (see below), then it inserts a
|
|
tab character.
|
|
|
|
@item
|
|
Otherwise, it indents the current line; this is done by calling the
|
|
function in @code{indent-line-function}. If the line is already
|
|
indented, and the value of @code{tab-always-indent} is @code{complete}
|
|
(see below), it tries completing the text at point.
|
|
@end itemize
|
|
|
|
If @var{rigid} is non-@code{nil} (interactively, with a prefix
|
|
argument), then after this command indents a line or inserts a tab, it
|
|
also rigidly indents the entire balanced expression which starts at
|
|
the beginning of the current line, in order to reflect the new
|
|
indentation. This argument is ignored if the command indents the
|
|
region.
|
|
@end deffn
|
|
|
|
@defvar indent-line-function
|
|
This variable's value is the function to be used by
|
|
@code{indent-for-tab-command}, and various other indentation commands,
|
|
to indent the current line. It is usually assigned by the major mode;
|
|
for instance, Lisp mode sets it to @code{lisp-indent-line}, C mode
|
|
sets it to @code{c-indent-line}, and so on. The default value is
|
|
@code{indent-relative}. @xref{Auto-Indentation}.
|
|
@end defvar
|
|
|
|
@deffn Command indent-according-to-mode
|
|
This command calls the function in @code{indent-line-function} to
|
|
indent the current line in a way appropriate for the current major mode.
|
|
@end deffn
|
|
|
|
@deffn Command newline-and-indent
|
|
This function inserts a newline, then indents the new line (the one
|
|
following the newline just inserted) according to the major mode. It
|
|
does indentation by calling @code{indent-according-to-mode}.
|
|
@end deffn
|
|
|
|
@deffn Command reindent-then-newline-and-indent
|
|
This command reindents the current line, inserts a newline at point,
|
|
and then indents the new line (the one following the newline just
|
|
inserted). It does indentation on both lines by calling
|
|
@code{indent-according-to-mode}.
|
|
@end deffn
|
|
|
|
@defopt tab-always-indent
|
|
This variable can be used to customize the behavior of the @key{TAB}
|
|
(@code{indent-for-tab-command}) command. If the value is @code{t}
|
|
(the default), the command normally just indents the current line. If
|
|
the value is @code{nil}, the command indents the current line only if
|
|
point is at the left margin or in the line's indentation; otherwise,
|
|
it inserts a tab character. If the value is @code{complete}, the
|
|
command first tries to indent the current line, and if the line was
|
|
already indented, it calls @code{completion-at-point} to complete the
|
|
text at point (@pxref{Completion in Buffers}).
|
|
@end defopt
|
|
|
|
@defopt tab-first-completion
|
|
If @code{tab-always-indent} is @code{complete}, whether to expand or
|
|
indent can be further customized via the @code{tab-first-completion}
|
|
variable. The following values can be used:
|
|
@table @code
|
|
@item eol
|
|
Only complete if point is at the end of a line.
|
|
|
|
@item word
|
|
Complete unless the next character has word syntax.
|
|
|
|
@item word-or-paren
|
|
Complete unless the next character has word syntax or is a
|
|
parenthesis.
|
|
|
|
@item word-or-paren-or-punct
|
|
Complete unless the next character has word syntax, or is a
|
|
parenthesis, or is punctuation.
|
|
@end table
|
|
|
|
In any case, typing @kbd{TAB} a second time always results in
|
|
completion.
|
|
@end defopt
|
|
|
|
@cindex literate programming
|
|
@cindex multi-mode indentation
|
|
Some major modes need to support embedded regions of text whose
|
|
syntax belongs to a different major mode. Examples include
|
|
@dfn{literate programming} source files that combine documentation and
|
|
snippets of source code, Yacc/Bison programs that include snippets of
|
|
Python or JS code, etc. To correctly indent the embedded chunks, the primary
|
|
mode needs to delegate the indentation to another mode's indentation
|
|
engine (e.g., call @code{js-indent-line} for JS code or
|
|
@code{python-indent-line} for Python), while providing it with some
|
|
context to guide the indentation. Major modes, for their part, should
|
|
avoid calling @code{widen} in their indentation code and obey
|
|
@code{prog-first-column}.
|
|
|
|
@defvar prog-indentation-context
|
|
This variable, when non-@code{nil}, holds the indentation context for
|
|
the sub-mode's indentation engine provided by the superior major mode.
|
|
The value should be a list of the form @code{(@var{first-column} . @var{rest}}.
|
|
The members of the list have the following meaning:
|
|
|
|
@table @var
|
|
@item first-column
|
|
The column to be used for top-level constructs. This replaces the
|
|
default value of the top-level column used by the sub-mode, usually
|
|
zero.
|
|
@item rest
|
|
This value is currently unused.
|
|
@end table
|
|
@end defvar
|
|
|
|
The following convenience function should be used by major mode's
|
|
indentation engine in support of invocations as sub-modes of another
|
|
major mode.
|
|
|
|
@defun prog-first-column
|
|
Call this function instead of using a literal value (usually, zero) of
|
|
the column number for indenting top-level program constructs. The
|
|
function's value is the column number to use for top-level constructs.
|
|
When no superior mode is in effect, this function returns zero.
|
|
@end defun
|
|
|
|
|
|
@node Region Indent
|
|
@subsection Indenting an Entire Region
|
|
|
|
This section describes commands that indent all the lines in the
|
|
region. They return unpredictable values.
|
|
|
|
@deffn Command indent-region start end &optional to-column
|
|
This command indents each nonblank line starting between @var{start}
|
|
(inclusive) and @var{end} (exclusive). If @var{to-column} is
|
|
@code{nil}, @code{indent-region} indents each nonblank line by calling
|
|
the current mode's indentation function, the value of
|
|
@code{indent-line-function}.
|
|
|
|
If @var{to-column} is non-@code{nil}, it should be an integer
|
|
specifying the number of columns of indentation; then this function
|
|
gives each line exactly that much indentation, by either adding or
|
|
deleting whitespace.
|
|
|
|
If there is a fill prefix, @code{indent-region} indents each line
|
|
by making it start with the fill prefix.
|
|
@end deffn
|
|
|
|
@defvar indent-region-function
|
|
The value of this variable is a function that can be used by
|
|
@code{indent-region} as a short cut. It should take two arguments, the
|
|
start and end of the region. You should design the function so
|
|
that it will produce the same results as indenting the lines of the
|
|
region one by one, but presumably faster.
|
|
|
|
If the value is @code{nil}, there is no short cut, and
|
|
@code{indent-region} actually works line by line.
|
|
|
|
A short-cut function is useful in modes such as C mode and Lisp mode,
|
|
where the @code{indent-line-function} must scan from the beginning of
|
|
the function definition: applying it to each line would be quadratic in
|
|
time. The short cut can update the scan information as it moves through
|
|
the lines indenting them; this takes linear time. In a mode where
|
|
indenting a line individually is fast, there is no need for a short cut.
|
|
|
|
@code{indent-region} with a non-@code{nil} argument @var{to-column} has
|
|
a different meaning and does not use this variable.
|
|
@end defvar
|
|
|
|
@deffn Command indent-rigidly start end count
|
|
This function indents all lines starting between @var{start}
|
|
(inclusive) and @var{end} (exclusive) sideways by @var{count} columns.
|
|
This preserves the shape of the affected region, moving it as a
|
|
rigid unit.
|
|
|
|
This is useful not only for indenting regions of unindented text, but
|
|
also for indenting regions of formatted code. For example, if
|
|
@var{count} is 3, this command adds 3 columns of indentation to every
|
|
line that begins in the specified region.
|
|
|
|
If called interactively with no prefix argument, this command invokes
|
|
a transient mode for adjusting indentation rigidly. @xref{Indentation
|
|
Commands,,, emacs, The GNU Emacs Manual}.
|
|
@end deffn
|
|
|
|
@deffn Command indent-code-rigidly start end columns &optional nochange-regexp
|
|
This is like @code{indent-rigidly}, except that it doesn't alter lines
|
|
that start within strings or comments.
|
|
|
|
In addition, it doesn't alter a line if @var{nochange-regexp} matches at
|
|
the beginning of the line (if @var{nochange-regexp} is non-@code{nil}).
|
|
@end deffn
|
|
|
|
@node Relative Indent
|
|
@subsection Indentation Relative to Previous Lines
|
|
|
|
This section describes two commands that indent the current line
|
|
based on the contents of previous lines.
|
|
|
|
@deffn Command indent-relative &optional first-only unindented-ok
|
|
This command inserts whitespace at point, extending to the same
|
|
column as the next @dfn{indent point} of the previous nonblank line. An
|
|
indent point is a non-whitespace character following whitespace. The
|
|
next indent point is the first one at a column greater than the current
|
|
column of point. For example, if point is underneath and to the left of
|
|
the first non-blank character of a line of text, it moves to that column
|
|
by inserting whitespace.
|
|
|
|
If the previous nonblank line has no next indent point (i.e., none at a
|
|
great enough column position), @code{indent-relative} either does
|
|
nothing (if @var{unindented-ok} is non-@code{nil}) or calls
|
|
@code{tab-to-tab-stop}. Thus, if point is underneath and to the right
|
|
of the last column of a short line of text, this command ordinarily
|
|
moves point to the next tab stop by inserting whitespace.
|
|
|
|
If @var{first-only} is non-@code{nil}, only the first indent point is
|
|
considered.
|
|
|
|
The return value of @code{indent-relative} is unpredictable.
|
|
|
|
In the following example, point is at the beginning of the second
|
|
line:
|
|
|
|
@example
|
|
@group
|
|
This line is indented twelve spaces.
|
|
@point{}The quick brown fox jumped.
|
|
@end group
|
|
@end example
|
|
|
|
@noindent
|
|
Evaluation of the expression @code{(indent-relative nil)} produces the
|
|
following:
|
|
|
|
@example
|
|
@group
|
|
This line is indented twelve spaces.
|
|
@point{}The quick brown fox jumped.
|
|
@end group
|
|
@end example
|
|
|
|
In this next example, point is between the @samp{m} and @samp{p} of
|
|
@samp{jumped}:
|
|
|
|
@example
|
|
@group
|
|
This line is indented twelve spaces.
|
|
The quick brown fox jum@point{}ped.
|
|
@end group
|
|
@end example
|
|
|
|
@noindent
|
|
Evaluation of the expression @code{(indent-relative nil)} produces the
|
|
following:
|
|
|
|
@example
|
|
@group
|
|
This line is indented twelve spaces.
|
|
The quick brown fox jum @point{}ped.
|
|
@end group
|
|
@end example
|
|
@end deffn
|
|
|
|
@deffn Command indent-relative-first-indent-point
|
|
@comment !!SourceFile indent.el
|
|
This command indents the current line like the previous nonblank line,
|
|
by calling @code{indent-relative} with @code{t} as the
|
|
@var{first-only} argument. The return value is unpredictable.
|
|
|
|
If the previous nonblank line has no indent points beyond the current
|
|
column, this command does nothing.
|
|
@end deffn
|
|
|
|
@node Indent Tabs
|
|
@subsection Adjustable Tab Stops
|
|
@cindex tabs stops for indentation
|
|
|
|
This section explains the mechanism for user-specified tab stops
|
|
and the mechanisms that use and set them. The name ``tab stops'' is
|
|
used because the feature is similar to that of the tab stops on a
|
|
typewriter. The feature works by inserting an appropriate number of
|
|
spaces and tab characters to reach the next tab stop column; it does not
|
|
affect the display of tab characters in the buffer (@pxref{Usual
|
|
Display}). Note that the @key{TAB} character as input uses this tab
|
|
stop feature only in a few major modes, such as Text mode.
|
|
@xref{Tab Stops,,, emacs, The GNU Emacs Manual}.
|
|
|
|
@deffn Command tab-to-tab-stop
|
|
This command inserts spaces or tabs before point, up to the next tab
|
|
stop column defined by @code{tab-stop-list}.
|
|
@end deffn
|
|
|
|
@defopt tab-stop-list
|
|
This variable defines the tab stop columns used by @code{tab-to-tab-stop}.
|
|
It should be either @code{nil}, or a list of increasing integers,
|
|
which need not be evenly spaced. The list is implicitly
|
|
extended to infinity through repetition of the interval between the
|
|
last and penultimate elements (or @code{tab-width} if the list has
|
|
fewer than two elements). A value of @code{nil} means a tab stop
|
|
every @code{tab-width} columns.
|
|
|
|
Use @kbd{M-x edit-tab-stops} to edit the location of tab stops interactively.
|
|
@end defopt
|
|
|
|
@node Motion by Indent
|
|
@subsection Indentation-Based Motion Commands
|
|
|
|
These commands, primarily for interactive use, act based on the
|
|
indentation in the text.
|
|
|
|
@deffn Command back-to-indentation
|
|
@comment !!SourceFile simple.el
|
|
This command moves point to the first non-whitespace character in the
|
|
current line (which is the line in which point is located).
|
|
@end deffn
|
|
|
|
@deffn Command backward-to-indentation &optional arg
|
|
@comment !!SourceFile simple.el
|
|
This command moves point backward @var{arg} lines and then to the
|
|
first nonblank character on that line. If @var{arg} is omitted or
|
|
@code{nil}, it defaults to 1.
|
|
@end deffn
|
|
|
|
@deffn Command forward-to-indentation &optional arg
|
|
@comment !!SourceFile simple.el
|
|
This command moves point forward @var{arg} lines and then to the first
|
|
nonblank character on that line. If @var{arg} is omitted or
|
|
@code{nil}, it defaults to 1.
|
|
@end deffn
|
|
|
|
@node Case Changes
|
|
@section Case Changes
|
|
@cindex case conversion in buffers
|
|
|
|
The case change commands described here work on text in the current
|
|
buffer. @xref{Case Conversion}, for case conversion functions that work
|
|
on strings and characters. @xref{Case Tables}, for how to customize
|
|
which characters are upper or lower case and how to convert them.
|
|
|
|
@deffn Command capitalize-region start end
|
|
This function capitalizes all words in the region defined by
|
|
@var{start} and @var{end}. To capitalize means to convert each word's
|
|
first character to upper case and convert the rest of each word to lower
|
|
case. The function returns @code{nil}.
|
|
|
|
If one end of the region is in the middle of a word, the part of the
|
|
word within the region is treated as an entire word.
|
|
|
|
When @code{capitalize-region} is called interactively, @var{start} and
|
|
@var{end} are point and the mark, with the smallest first.
|
|
|
|
@example
|
|
@group
|
|
---------- Buffer: foo ----------
|
|
This is the contents of the 5th foo.
|
|
---------- Buffer: foo ----------
|
|
@end group
|
|
|
|
@group
|
|
(capitalize-region 1 37)
|
|
@result{} nil
|
|
|
|
---------- Buffer: foo ----------
|
|
This Is The Contents Of The 5th Foo.
|
|
---------- Buffer: foo ----------
|
|
@end group
|
|
@end example
|
|
@end deffn
|
|
|
|
@deffn Command downcase-region start end
|
|
This function converts all of the letters in the region defined by
|
|
@var{start} and @var{end} to lower case. The function returns
|
|
@code{nil}.
|
|
|
|
When @code{downcase-region} is called interactively, @var{start} and
|
|
@var{end} are point and the mark, with the smallest first.
|
|
@end deffn
|
|
|
|
@deffn Command upcase-region start end
|
|
This function converts all of the letters in the region defined by
|
|
@var{start} and @var{end} to upper case. The function returns
|
|
@code{nil}.
|
|
|
|
When @code{upcase-region} is called interactively, @var{start} and
|
|
@var{end} are point and the mark, with the smallest first.
|
|
@end deffn
|
|
|
|
@deffn Command capitalize-word count
|
|
This function capitalizes @var{count} words after point, moving point
|
|
over as it does. To capitalize means to convert each word's first
|
|
character to upper case and convert the rest of each word to lower case.
|
|
If @var{count} is negative, the function capitalizes the
|
|
@minus{}@var{count} previous words but does not move point. The value
|
|
is @code{nil}.
|
|
|
|
If point is in the middle of a word, the part of the word before point
|
|
is ignored when moving forward. The rest is treated as an entire word.
|
|
|
|
When @code{capitalize-word} is called interactively, @var{count} is
|
|
set to the numeric prefix argument.
|
|
@end deffn
|
|
|
|
@deffn Command downcase-word count
|
|
This function converts the @var{count} words after point to all lower
|
|
case, moving point over as it does. If @var{count} is negative, it
|
|
converts the @minus{}@var{count} previous words but does not move point.
|
|
The value is @code{nil}.
|
|
|
|
When @code{downcase-word} is called interactively, @var{count} is set
|
|
to the numeric prefix argument.
|
|
@end deffn
|
|
|
|
@deffn Command upcase-word count
|
|
This function converts the @var{count} words after point to all upper
|
|
case, moving point over as it does. If @var{count} is negative, it
|
|
converts the @minus{}@var{count} previous words but does not move point.
|
|
The value is @code{nil}.
|
|
|
|
When @code{upcase-word} is called interactively, @var{count} is set to
|
|
the numeric prefix argument.
|
|
@end deffn
|
|
|
|
@node Text Properties
|
|
@section Text Properties
|
|
@cindex text properties
|
|
@cindex attributes of text
|
|
@cindex properties of text
|
|
|
|
Each character position in a buffer or a string can have a @dfn{text
|
|
property list}, much like the property list of a symbol (@pxref{Property
|
|
Lists}). The properties belong to a particular character at a
|
|
particular place, such as, the letter @samp{T} at the beginning of this
|
|
sentence or the first @samp{o} in @samp{foo}---if the same character
|
|
occurs in two different places, the two occurrences in general have
|
|
different properties.
|
|
|
|
Each property has a name and a value. Both of these can be any Lisp
|
|
object, but the name is normally a symbol. Typically each property
|
|
name symbol is used for a particular purpose; for instance, the text
|
|
property @code{face} specifies the faces for displaying the character
|
|
(@pxref{Special Properties}). The usual way to access the property
|
|
list is to specify a name and ask what value corresponds to it.
|
|
|
|
If a character has a @code{category} property, we call it the
|
|
@dfn{property category} of the character. It should be a symbol. The
|
|
properties of the symbol serve as defaults for the properties of the
|
|
character.
|
|
|
|
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}. Killing
|
|
and then yanking text (@pxref{The Kill Ring}) also preserves the
|
|
properties, except that some properties are handled specially and
|
|
might be removed when text is yanked; @pxref{Yanking}.
|
|
|
|
@menu
|
|
* Examining Properties:: Looking at the properties of one character.
|
|
* Changing Properties:: Setting the properties of a range of text.
|
|
* Property Search:: Searching for where a property changes value.
|
|
* Special Properties:: Particular properties with special meanings.
|
|
* Format Properties:: Properties for representing formatting of text.
|
|
* Sticky Properties:: How inserted text gets properties from
|
|
neighboring text.
|
|
* Lazy Properties:: Computing text properties in a lazy fashion
|
|
only when text is examined.
|
|
* Clickable Text:: Using text properties to make regions of text
|
|
do something when you click on them.
|
|
* Fields:: The @code{field} property defines
|
|
fields within the buffer.
|
|
* Not Intervals:: Why text properties do not use
|
|
Lisp-visible text intervals.
|
|
@end menu
|
|
|
|
@node Examining Properties
|
|
@subsection Examining Text Properties
|
|
@cindex examining text properties
|
|
@cindex text properties, examining
|
|
|
|
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. @xref{Property Search}, for
|
|
functions to examine the properties of a number of characters at once.
|
|
|
|
These functions handle both strings and buffers. Keep in mind that
|
|
positions in a string start from 0, whereas positions in a buffer start
|
|
from 1. Passing a buffer other than the current buffer may be slow.
|
|
|
|
@defun get-text-property pos prop &optional object
|
|
This function returns the value of the @var{prop} property of the
|
|
character after position @var{pos} in @var{object} (a buffer or
|
|
string). The argument @var{object} is optional and defaults to the
|
|
current buffer.
|
|
|
|
If @var{position} is at the end of @var{object}, the value is
|
|
@code{nil}, but note that buffer narrowing does not affect the value.
|
|
That is, if @var{object} is a buffer or @code{nil}, and the buffer is
|
|
narrowed and @var{position} is at the end of the narrowed buffer, the
|
|
result may be non-@code{nil}.
|
|
|
|
If there is no @var{prop} property strictly speaking, but the character
|
|
has a property category that is a symbol, then @code{get-text-property} returns
|
|
the @var{prop} property of that symbol.
|
|
@end defun
|
|
|
|
@defun get-char-property position prop &optional object
|
|
This function is like @code{get-text-property}, except that it checks
|
|
overlays first and then text properties. @xref{Overlays}.
|
|
|
|
The argument @var{object} may be a string, a buffer, or a window. If
|
|
it is a window, then the buffer displayed in that window is used for
|
|
text properties and overlays, but only the overlays active for that
|
|
window are considered. If @var{object} is a buffer, then overlays in
|
|
that buffer are considered first, in order of decreasing priority,
|
|
followed by the text properties. If @var{object} is a string, only
|
|
text properties are considered, since strings never have overlays.
|
|
@end defun
|
|
|
|
@defun get-pos-property position prop &optional object
|
|
This function is like @code{get-char-property}, except that it pays
|
|
attention to properties' stickiness and overlays' advancement settings
|
|
instead of the property of the character at (i.e., right after)
|
|
@var{position}.
|
|
@end defun
|
|
|
|
@defun get-char-property-and-overlay position prop &optional object
|
|
This is like @code{get-char-property}, but gives extra information
|
|
about the overlay that the property value comes from.
|
|
|
|
Its value is a cons cell whose @sc{car} is the property value, the
|
|
same value @code{get-char-property} would return with the same
|
|
arguments. Its @sc{cdr} is the overlay in which the property was
|
|
found, or @code{nil}, if it was found as a text property or not found
|
|
at all.
|
|
|
|
If @var{position} is at the end of @var{object}, both the @sc{car} and
|
|
the @sc{cdr} of the value are @code{nil}.
|
|
@end defun
|
|
|
|
@defvar char-property-alias-alist
|
|
This variable holds an alist which maps property names to a list of
|
|
alternative property names. If a character does not specify a direct
|
|
value for a property, the alternative property names are consulted in
|
|
order; the first non-@code{nil} value is used. This variable takes
|
|
precedence over @code{default-text-properties}, and @code{category}
|
|
properties take precedence over this variable.
|
|
@end defvar
|
|
|
|
@defun text-properties-at position &optional object
|
|
This function returns the entire property list of the character at
|
|
@var{position} in the string or buffer @var{object}. If @var{object} is
|
|
@code{nil}, it defaults to the current buffer.
|
|
|
|
If @var{position} is at the end of @var{object}, the value is
|
|
@code{nil}, but note that buffer narrowing does not affect the value.
|
|
That is, if @var{object} is a buffer or @code{nil}, and the buffer is
|
|
narrowed and @var{position} is at the end of the narrowed buffer, the
|
|
result may be non-@code{nil}.
|
|
@end defun
|
|
|
|
@defvar default-text-properties
|
|
This variable holds a property list giving default values for text
|
|
properties. Whenever a character does not specify a value for a
|
|
property, neither directly, through a category symbol, or through
|
|
@code{char-property-alias-alist}, the value stored in this list is
|
|
used instead. Here is an example:
|
|
|
|
@example
|
|
(setq default-text-properties '(foo 69)
|
|
char-property-alias-alist nil)
|
|
;; @r{Make sure character 1 has no properties of its own.}
|
|
(set-text-properties 1 2 nil)
|
|
;; @r{What we get, when we ask, is the default value.}
|
|
(get-text-property 1 'foo)
|
|
@result{} 69
|
|
@end example
|
|
@end defvar
|
|
|
|
@defun object-intervals OBJECT
|
|
This function returns a copy of the intervals (i.e., text properties)
|
|
in @var{object} as a list of intervals. @var{object} must be a string
|
|
or a buffer. Altering the structure of this list does not change the
|
|
intervals in the object.
|
|
|
|
@example
|
|
(object-intervals (propertize "foo" 'face 'bold))
|
|
@result{} ((0 3 (face bold)))
|
|
@end example
|
|
|
|
Each element in the returned list represents one interval. Each
|
|
interval has three parts: The first is the start, the second is the
|
|
end, and the third part is the text property itself.
|
|
@end defun
|
|
|
|
@node Changing Properties
|
|
@subsection Changing Text Properties
|
|
@cindex changing text properties
|
|
@cindex text properties, changing
|
|
|
|
The primitives for changing properties apply to a specified range of
|
|
text in a buffer or string. The function @code{set-text-properties}
|
|
(see end of section) sets the entire property list of the text in that
|
|
range; more often, it is useful to add, change, or delete just certain
|
|
properties specified by name.
|
|
|
|
Since text properties are considered part of the contents of the
|
|
buffer (or string), and can affect how a buffer looks on the screen,
|
|
any change in buffer text properties marks the buffer as modified.
|
|
Buffer text property changes are undoable also (@pxref{Undo}).
|
|
Positions in a string start from 0, whereas positions in a buffer
|
|
start from 1.
|
|
|
|
@defun put-text-property start end prop value &optional object
|
|
This function sets the @var{prop} property to @var{value} for the text
|
|
between @var{start} and @var{end} in the string or buffer @var{object}.
|
|
If @var{object} is @code{nil}, it defaults to the current buffer.
|
|
@end defun
|
|
|
|
@defun add-text-properties start end props &optional object
|
|
This function adds or overrides text properties for the text between
|
|
@var{start} and @var{end} in the string or buffer @var{object}. If
|
|
@var{object} is @code{nil}, it defaults to the current buffer.
|
|
|
|
The argument @var{props} specifies which properties to add. It should
|
|
have the form of a property list (@pxref{Property Lists}): a list whose
|
|
elements include the property names followed alternately by the
|
|
corresponding values.
|
|
|
|
The return value is @code{t} if the function actually changed some
|
|
property's value; @code{nil} otherwise (if @var{props} is @code{nil} or
|
|
its values agree with those in the text).
|
|
|
|
For example, here is how to set the @code{comment} and @code{face}
|
|
properties of a range of text:
|
|
|
|
@example
|
|
(add-text-properties @var{start} @var{end}
|
|
'(comment t face highlight))
|
|
@end example
|
|
@end defun
|
|
|
|
@defun remove-text-properties start end props &optional object
|
|
This function deletes specified text properties from the text between
|
|
@var{start} and @var{end} in the string or buffer @var{object}. If
|
|
@var{object} is @code{nil}, it defaults to the current buffer.
|
|
|
|
The argument @var{props} specifies which properties to delete. It
|
|
should have the form of a property list (@pxref{Property Lists}): a list
|
|
whose elements are property names alternating with corresponding values.
|
|
But only the names matter---the values that accompany them are ignored.
|
|
For example, here's how to remove the @code{face} property.
|
|
|
|
@example
|
|
(remove-text-properties @var{start} @var{end} '(face nil))
|
|
@end example
|
|
|
|
The return value is @code{t} if the function actually changed some
|
|
property's value; @code{nil} otherwise (if @var{props} is @code{nil} or
|
|
if no character in the specified text had any of those properties).
|
|
|
|
To remove all text properties from certain text, use
|
|
@code{set-text-properties} and specify @code{nil} for the new property
|
|
list.
|
|
@end defun
|
|
|
|
@defun remove-list-of-text-properties start end list-of-properties &optional object
|
|
Like @code{remove-text-properties} except that
|
|
@var{list-of-properties} is a list of property names only, not an
|
|
alternating list of property names and values.
|
|
@end defun
|
|
|
|
@defun set-text-properties start end props &optional object
|
|
This function completely replaces the text property list for the text
|
|
between @var{start} and @var{end} in the string or buffer @var{object}.
|
|
If @var{object} is @code{nil}, it defaults to the current buffer.
|
|
|
|
The argument @var{props} is the new property list. It should be a list
|
|
whose elements are property names alternating with corresponding values.
|
|
|
|
After @code{set-text-properties} returns, all the characters in the
|
|
specified range have identical properties.
|
|
|
|
If @var{props} is @code{nil}, the effect is to get rid of all properties
|
|
from the specified range of text. Here's an example:
|
|
|
|
@example
|
|
(set-text-properties @var{start} @var{end} nil)
|
|
@end example
|
|
|
|
Do not rely on the return value of this function.
|
|
@end defun
|
|
|
|
@defun add-face-text-property start end face &optional appendp object
|
|
This function acts on the text between @var{start} and @var{end},
|
|
adding the face @var{face} to the @code{face} text property.
|
|
@var{face} should be a valid value for the @code{face} property
|
|
(@pxref{Special Properties}), such as a face name or an anonymous face
|
|
(@pxref{Faces}).
|
|
|
|
If any text in the region already has a non-@code{nil} @code{face} property,
|
|
those face(s) are retained. This function sets the @code{face}
|
|
property to a list of faces, with @var{face} as the first element (by
|
|
default) and the pre-existing faces as the remaining elements. If the
|
|
optional argument @var{appendp} is non-@code{nil}, @var{face} is
|
|
appended to the end of the list instead. Note that in a face list,
|
|
the first occurring value for each attribute takes precedence.
|
|
|
|
For example, the following code would assign an italicized green face
|
|
to the text between @var{start} and @var{end}:
|
|
|
|
@example
|
|
(add-face-text-property @var{start} @var{end} 'italic)
|
|
(add-face-text-property @var{start} @var{end} '(:foreground "red"))
|
|
(add-face-text-property @var{start} @var{end} '(:foreground "green"))
|
|
@end example
|
|
|
|
The optional argument @var{object}, if non-@code{nil}, specifies a
|
|
buffer or string to act on, rather than the current buffer. If
|
|
@var{object} is a string, then @var{start} and @var{end} are
|
|
zero-based indices into the string.
|
|
@end defun
|
|
|
|
The easiest way to make a string with text properties is with
|
|
@code{propertize}:
|
|
|
|
@defun propertize string &rest properties
|
|
This function returns a copy of @var{string} with the text properties
|
|
@var{properties} added. These properties apply to all the characters
|
|
in the string that is returned. Here is an example that constructs a
|
|
string with a @code{face} property and a @code{mouse-face} property:
|
|
|
|
@smallexample
|
|
(propertize "foo" 'face 'italic
|
|
'mouse-face 'bold-italic)
|
|
@result{} #("foo" 0 3 (mouse-face bold-italic face italic))
|
|
@end smallexample
|
|
|
|
To put different properties on various parts of a string, you can
|
|
construct each part with @code{propertize} and then combine them with
|
|
@code{concat}:
|
|
|
|
@smallexample
|
|
(concat
|
|
(propertize "foo" 'face 'italic
|
|
'mouse-face 'bold-italic)
|
|
" and "
|
|
(propertize "bar" 'face 'italic
|
|
'mouse-face 'bold-italic))
|
|
@result{} #("foo and bar"
|
|
0 3 (face italic mouse-face bold-italic)
|
|
3 8 nil
|
|
8 11 (face italic mouse-face bold-italic))
|
|
@end smallexample
|
|
@end defun
|
|
|
|
@xref{Buffer Contents}, for the function
|
|
@code{buffer-substring-no-properties}, which copies text from the
|
|
buffer but does not copy its properties.
|
|
|
|
@findex with-silent-modifications, and changes in text properties
|
|
If you wish to add text properties to a buffer or remove them
|
|
without marking the buffer as modified, you can wrap the calls above
|
|
in the @code{with-silent-modifications} macro. @xref{Buffer
|
|
Modification}.
|
|
|
|
@node Property Search
|
|
@subsection Text Property Search Functions
|
|
@cindex searching text properties
|
|
@cindex text properties, searching
|
|
|
|
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.
|
|
|
|
Here are functions you can use to do this. They use @code{eq} for
|
|
comparing property values. In all cases, @var{object} defaults to the
|
|
current buffer.
|
|
|
|
For good performance, it's very important to use the @var{limit}
|
|
argument to these functions, especially the ones that search for a
|
|
single property---otherwise, they may spend a long time scanning to the
|
|
end of the buffer, if the property you are interested in does not change.
|
|
|
|
These functions do not move point; instead, they return a position (or
|
|
@code{nil}). Remember that a position is always between two characters;
|
|
the position returned by these functions is between two characters with
|
|
different properties.
|
|
|
|
@defun next-property-change pos &optional object limit
|
|
The function scans the text forward from position @var{pos} in the
|
|
string or buffer @var{object} until it finds a change in some text
|
|
property, then returns the position of the change. In other words, it
|
|
returns the position of the first character beyond @var{pos} whose
|
|
properties are not identical to those of the character just after
|
|
@var{pos}.
|
|
|
|
If @var{limit} is non-@code{nil}, then the scan ends at position
|
|
@var{limit}. If there is no property change before that point, this
|
|
function returns @var{limit}.
|
|
|
|
The value is @code{nil} if the properties remain unchanged all the way
|
|
to the end of @var{object} and @var{limit} is @code{nil}. If the value
|
|
is non-@code{nil}, it is a position greater than or equal to @var{pos}.
|
|
The value equals @var{pos} only when @var{limit} equals @var{pos}.
|
|
|
|
Here is an example of how to scan the buffer by chunks of text within
|
|
which all properties are constant:
|
|
|
|
@smallexample
|
|
(while (not (eobp))
|
|
(let ((plist (text-properties-at (point)))
|
|
(next-change
|
|
(or (next-property-change (point) (current-buffer))
|
|
(point-max))))
|
|
@r{Process text from point to @var{next-change}@dots{}}
|
|
(goto-char next-change)))
|
|
@end smallexample
|
|
@end defun
|
|
|
|
@defun previous-property-change pos &optional object limit
|
|
This is like @code{next-property-change}, but scans back from @var{pos}
|
|
instead of forward. If the value is non-@code{nil}, it is a position
|
|
less than or equal to @var{pos}; it equals @var{pos} only if @var{limit}
|
|
equals @var{pos}.
|
|
@end defun
|
|
|
|
@defun next-single-property-change pos prop &optional object limit
|
|
The function scans text for a change in the @var{prop} property, then
|
|
returns the position of the change. The scan goes forward from
|
|
position @var{pos} in the string or buffer @var{object}. In other
|
|
words, this function returns the position of the first character
|
|
beyond @var{pos} whose @var{prop} property differs from that of the
|
|
character just after @var{pos}.
|
|
|
|
If @var{limit} is non-@code{nil}, then the scan ends at position
|
|
@var{limit}. If there is no property change before that point,
|
|
@code{next-single-property-change} returns @var{limit}.
|
|
|
|
The value is @code{nil} if the property remains unchanged all the way to
|
|
the end of @var{object} and @var{limit} is @code{nil}. If the value is
|
|
non-@code{nil}, it is a position greater than or equal to @var{pos}; it
|
|
equals @var{pos} only if @var{limit} equals @var{pos}.
|
|
@end defun
|
|
|
|
@defun previous-single-property-change pos prop &optional object limit
|
|
This is like @code{next-single-property-change}, but scans back from
|
|
@var{pos} instead of forward. If the value is non-@code{nil}, it is a
|
|
position less than or equal to @var{pos}; it equals @var{pos} only if
|
|
@var{limit} equals @var{pos}.
|
|
@end defun
|
|
|
|
@defun next-char-property-change pos &optional limit
|
|
This is like @code{next-property-change} except that it considers
|
|
overlay properties as well as text properties, and if no change is
|
|
found before the end of the buffer, it returns the maximum buffer
|
|
position rather than @code{nil} (in this sense, it resembles the
|
|
corresponding overlay function @code{next-overlay-change}, rather than
|
|
@code{next-property-change}). There is no @var{object} operand
|
|
because this function operates only on the current buffer. It returns
|
|
the next address at which either kind of property changes.
|
|
@end defun
|
|
|
|
@defun previous-char-property-change pos &optional limit
|
|
This is like @code{next-char-property-change}, but scans back from
|
|
@var{pos} instead of forward, and returns the minimum buffer
|
|
position if no change is found.
|
|
@end defun
|
|
|
|
@defun next-single-char-property-change pos prop &optional object limit
|
|
This is like @code{next-single-property-change} except that it
|
|
considers overlay properties as well as text properties, and if no
|
|
change is found before the end of the @var{object}, it returns the
|
|
maximum valid position in @var{object} rather than @code{nil}. Unlike
|
|
@code{next-char-property-change}, this function @emph{does} have an
|
|
@var{object} operand; if @var{object} is not a buffer, only
|
|
text-properties are considered.
|
|
@end defun
|
|
|
|
@defun previous-single-char-property-change pos prop &optional object limit
|
|
This is like @code{next-single-char-property-change}, but scans back
|
|
from @var{pos} instead of forward, and returns the minimum valid
|
|
position in @var{object} if no change is found.
|
|
@end defun
|
|
|
|
@defun text-property-any start end prop value &optional object
|
|
This function returns non-@code{nil} if at least one character between
|
|
@var{start} and @var{end} has a property @var{prop} whose value is
|
|
@var{value}. More precisely, it returns the position of the first such
|
|
character. Otherwise, it returns @code{nil}.
|
|
|
|
The optional fifth argument, @var{object}, specifies the string or
|
|
buffer to scan. Positions are relative to @var{object}. The default
|
|
for @var{object} is the current buffer.
|
|
@end defun
|
|
|
|
@defun text-property-not-all start end prop value &optional object
|
|
This function returns non-@code{nil} if at least one character between
|
|
@var{start} and @var{end} does not have a property @var{prop} with value
|
|
@var{value}. More precisely, it returns the position of the first such
|
|
character. Otherwise, it returns @code{nil}.
|
|
|
|
The optional fifth argument, @var{object}, specifies the string or
|
|
buffer to scan. Positions are relative to @var{object}. The default
|
|
for @var{object} is the current buffer.
|
|
@end defun
|
|
|
|
@defun text-property-search-forward prop &optional value predicate not-current
|
|
Search for the next region of text whose property @var{prop} is a
|
|
match for @var{value} (which defaults to @code{nil}), according to
|
|
@var{predicate}.
|
|
|
|
This function is modeled after @code{search-forward} (@pxref{String
|
|
Search}) and friends, in that it moves point, but it also returns a
|
|
structure that describes the match instead of returning it in
|
|
@code{match-beginning} and friends.
|
|
|
|
If the text property whose value is a match can't be found, the
|
|
function returns @code{nil}. If it's found, point is placed at the
|
|
end of the region that has this matching text property, and the
|
|
function returns a @code{prop-match} structure with information about
|
|
the match.
|
|
|
|
@var{predicate} can either be @code{t} (which is a synonym for
|
|
@code{equal}), @code{nil} (which means ``not equal''), or a predicate
|
|
that will be called with two arguments: @var{value} and the value of
|
|
the text property @var{prop} at the buffer position that is a
|
|
candidate for a match. The function should return non-@code{nil} if
|
|
there's a match, @code{nil} otherwise.
|
|
|
|
If @var{not-current} is non-@code{nil}, then if point is already in a
|
|
region where we have a property match, skip past that region and find
|
|
the next region instead.
|
|
|
|
The @code{prop-match} structure has the following accessor functions:
|
|
@code{prop-match-beginning} (the start of the match),
|
|
@code{prop-match-end} (the end of the match), and
|
|
@code{prop-match-value} (the value of @var{property} at the start of
|
|
the match).
|
|
|
|
In the examples below, we use a buffer whose contents is:
|
|
|
|
@display
|
|
This is a @b{bold} and here's @b{@i{bolditalic}} and this is the end.
|
|
@end display
|
|
|
|
That is, the ``bold'' words are the @code{bold} face, and the
|
|
``italic'' word is in the @code{italic} face.
|
|
|
|
With point at the start:
|
|
|
|
@lisp
|
|
(while (setq match (text-property-search-forward 'face 'bold t))
|
|
(push (buffer-substring (prop-match-beginning match)
|
|
(prop-match-end match))
|
|
words))
|
|
@end lisp
|
|
|
|
This will pick out all the words that use the @code{bold} face.
|
|
|
|
@lisp
|
|
(while (setq match (text-property-search-forward 'face nil t))
|
|
(push (buffer-substring (prop-match-beginning match)
|
|
(prop-match-end match))
|
|
words))
|
|
@end lisp
|
|
|
|
This will pick out all the bits that have no face properties, which
|
|
will result in the list @samp{(@w{"This is a "} @w{"and here's "}
|
|
@w{"and this is the end"})} (only in reverse order, since we used
|
|
@code{push}, @pxref{List Variables}).
|
|
|
|
@lisp
|
|
(while (setq match (text-property-search-forward 'face nil nil))
|
|
(push (buffer-substring (prop-match-beginning match)
|
|
(prop-match-end match))
|
|
words))
|
|
@end lisp
|
|
|
|
This will pick out all the regions where @code{face} is set to
|
|
something, but this is split up into where the properties change, so
|
|
the result here will be @samp{("bold" "bold" "italic")}.
|
|
|
|
For a more realistic example where you might use this, consider that
|
|
you have a buffer where certain sections represent URLs, and these are
|
|
tagged with @code{shr-url}.
|
|
|
|
@lisp
|
|
(while (setq match (text-property-search-forward 'shr-url nil nil))
|
|
(push (prop-match-value match) urls))
|
|
@end lisp
|
|
|
|
This will give you a list of all those URLs.
|
|
|
|
@end defun
|
|
|
|
@defun text-property-search-backward prop &optional value predicate not-current
|
|
This is just like @code{text-property-search-forward}, but searches
|
|
backward instead, and if a match is found, point is placed at the
|
|
beginning of the matched region instead of the end.
|
|
@end defun
|
|
|
|
|
|
@node Special Properties
|
|
@subsection Properties with Special Meanings
|
|
|
|
Here is a table of text property names that have special built-in
|
|
meanings. The following sections list a few additional special property
|
|
names that control filling and property inheritance. All other names
|
|
have no standard meaning, and you can use them as you like.
|
|
|
|
Note: the properties @code{composition}, @code{display},
|
|
@code{invisible} and @code{intangible} can also cause point to move to
|
|
an acceptable place, after each Emacs command. @xref{Adjusting
|
|
Point}.
|
|
|
|
@table @code
|
|
@cindex property category of text character
|
|
@c FIXME: Isn't @kindex for keyboard commands?
|
|
@kindex category @r{(text property)}
|
|
@item category
|
|
If a character has a @code{category} property, we call it the
|
|
@dfn{property category} of the character. It should be a symbol. The
|
|
properties of this symbol serve as defaults for the properties of the
|
|
character.
|
|
|
|
@item face
|
|
@cindex face codes of text
|
|
@kindex face @r{(text property)}
|
|
The @code{face} property controls the appearance of the character
|
|
(@pxref{Faces}). The value of the property can be the following:
|
|
|
|
@itemize @bullet
|
|
@item
|
|
A face name (a symbol or string).
|
|
|
|
@item
|
|
An anonymous face: a property list of the form @code{(@var{keyword}
|
|
@var{value} @dots{})}, where each @var{keyword} is a face attribute
|
|
name and @var{value} is a value for that attribute.
|
|
|
|
@item
|
|
A list of faces. Each list element should be either a face name or an
|
|
anonymous face. This specifies a face which is an aggregate of the
|
|
attributes of each of the listed faces. Faces occurring earlier in
|
|
the list have higher priority.
|
|
|
|
@item
|
|
A cons cell of the form @code{(foreground-color . @var{color-name})}
|
|
or @code{(background-color . @var{color-name})}. This specifies the
|
|
foreground or background color, similar to @code{(:foreground
|
|
@var{color-name})} or @code{(:background @var{color-name})}. This
|
|
form is supported for backward compatibility only, and should be
|
|
avoided.
|
|
|
|
@item
|
|
A cons cell of the form @w{@code{(:filtered @var{filter}
|
|
@var{face-spec})}}, that specifies the face given by @var{face-spec},
|
|
but only if @var{filter} matches when the face is used for display.
|
|
The @var{face-spec} can use any of the forms mentioned above. The
|
|
@var{filter} should be of the form @w{@code{(:window @var{param}
|
|
@var{value})}}, which matches for windows whose parameter @var{param}
|
|
is @code{eq} to @var{value}. If the variable
|
|
@code{face-filters-always-match} is non-@code{nil}, all face filters
|
|
are deemed to have matched.
|
|
@end itemize
|
|
|
|
Font Lock mode (@pxref{Font Lock Mode}) works in most buffers by
|
|
dynamically updating the @code{face} property of characters based on
|
|
the context.
|
|
|
|
The @code{add-face-text-property} function provides a convenient way
|
|
to set this text property. @xref{Changing Properties}.
|
|
|
|
@kindex font-lock-face @r{(text property)}
|
|
@item font-lock-face
|
|
This property specifies a value for the @code{face} property that Font
|
|
Lock mode should apply to the underlying text. It is one of the
|
|
fontification methods used by Font Lock mode, and is useful for
|
|
special modes that implement their own highlighting.
|
|
@xref{Precalculated Fontification}. When Font Lock mode is disabled,
|
|
@code{font-lock-face} has no effect.
|
|
|
|
@kindex mouse-face @r{(text property)}
|
|
@item mouse-face
|
|
This property is used instead of @code{face} when the mouse pointer
|
|
hovers over the text which has this property. When this happens, the
|
|
entire stretch of text that has the same @code{mouse-face} property
|
|
value, not just the character under the mouse, is highlighted.
|
|
|
|
Emacs ignores all face attributes from the @code{mouse-face} property
|
|
that alter the text size (e.g., @code{:height}, @code{:weight}, and
|
|
@code{:slant}). Those attributes are always the same as for the
|
|
unhighlighted text.
|
|
|
|
@kindex cursor-face @r{(text property)}
|
|
@findex cursor-face-highlight-mode
|
|
@vindex cursor-face-highlight-nonselected-window
|
|
@item cursor-face
|
|
This property is similar to @code{mouse-face}, but it is used when
|
|
point (not the mouse) is inside text that has this property. The
|
|
highlighting happens only if the mode
|
|
@code{cursor-face-highlight-mode} is enabled. When the variable
|
|
@code{cursor-face-highlight-nonselected-window} is non-@code{nil}, the
|
|
text with this face is highlighted even if the window is not selected,
|
|
similarly to what @code{highlight-nonselected-windows} does for the
|
|
region (@pxref{Mark,, The Mark and the Region, emacs, The GNU Emacs
|
|
Manual}).
|
|
|
|
@kindex fontified @r{(text property)}
|
|
@item fontified
|
|
This property says whether the text is ready for display. If
|
|
@code{nil}, Emacs's redisplay routine calls the functions in
|
|
@code{fontification-functions} (@pxref{Auto Faces}) to prepare this
|
|
part of the buffer before it is displayed. It is used internally by
|
|
the just-in-time font locking code.
|
|
|
|
@item display
|
|
This property activates various features that change the
|
|
way text is displayed. For example, it can make text appear taller
|
|
or shorter, higher or lower, wider or narrow, or replaced with an image.
|
|
@xref{Display Property}.
|
|
|
|
@kindex help-echo @r{(text property)}
|
|
@cindex tooltip for help strings
|
|
@item help-echo
|
|
@anchor{Text help-echo}
|
|
If text has a string as its @code{help-echo} property, then when you
|
|
move the mouse onto that text, Emacs displays that string in the echo
|
|
area, or in the tooltip window (@pxref{Tooltips}), after passing it
|
|
through @code{substitute-command-keys}.
|
|
|
|
If the value of the @code{help-echo} property is a function, that
|
|
function is called with three arguments, @var{window}, @var{object} and
|
|
@var{pos} and should return a help string or @code{nil} for
|
|
none. The first argument, @var{window} is the window in which
|
|
the help was found. The second, @var{object}, is the buffer, overlay or
|
|
string which had the @code{help-echo} property. The @var{pos}
|
|
argument is as follows:
|
|
|
|
@itemize @bullet{}
|
|
@item
|
|
If @var{object} is a buffer, @var{pos} is the position in the buffer.
|
|
@item
|
|
If @var{object} is an overlay, that overlay has a @code{help-echo}
|
|
property, and @var{pos} is the position in the overlay's buffer.
|
|
@item
|
|
If @var{object} is a string (an overlay string or a string displayed
|
|
with the @code{display} property), @var{pos} is the position in that
|
|
string.
|
|
@end itemize
|
|
|
|
If the value of the @code{help-echo} property is neither a function nor
|
|
a string, it is evaluated to obtain a help string.
|
|
|
|
You can alter the way help text is displayed by setting the variable
|
|
@code{show-help-function} (@pxref{Help display}).
|
|
|
|
This feature is used in the mode line and for other active text.
|
|
|
|
@cindex help-echo text, avoid command-key substitution
|
|
@kindex help-echo-inhibit-substitution @r{(text property)}
|
|
@item help-echo-inhibit-substitution
|
|
If the first character of a @code{help-echo} string has a
|
|
non-@code{nil} @code{help-echo-inhibit-substitution} property, then it
|
|
is displayed as-is by @code{show-help-function}, without being passed
|
|
through @code{substitute-command-keys}.
|
|
|
|
@cindex help-echo text on fringes
|
|
@item left-fringe-help
|
|
@itemx right-fringe-help
|
|
If any visible text of a screen line has the @code{left-fringe-help} or
|
|
@code{right-fringe-help} text property whose value is a string, then
|
|
that string will be displayed when the mouse pointer hovers over the
|
|
corresponding line's fringe through @code{show-help-function}
|
|
(@pxref{Help display}). This is useful when used together with fringe
|
|
cursors and bitmaps (@pxref{Fringes}).
|
|
|
|
@cindex keymap of character
|
|
@kindex keymap @r{(text property)}
|
|
@item keymap
|
|
The @code{keymap} property specifies an additional keymap for
|
|
commands. When this keymap applies, it is used for key lookup before
|
|
the minor mode keymaps and before the buffer's local map.
|
|
@xref{Active Keymaps}. If the property value is a symbol, the
|
|
symbol's function definition is used as the keymap.
|
|
|
|
The property's value for the character before point applies if it is
|
|
non-@code{nil} and rear-sticky, and the property's value for the
|
|
character after point applies if it is non-@code{nil} and
|
|
front-sticky. (For mouse clicks, the position of the click is used
|
|
instead of the position of point.)
|
|
|
|
@kindex local-map @r{(text property)}
|
|
@item local-map
|
|
This property works like @code{keymap} except that it specifies a
|
|
keymap to use @emph{instead of} the buffer's local map. For most
|
|
purposes (perhaps all purposes), it is better to use the @code{keymap}
|
|
property.
|
|
|
|
@item syntax-table
|
|
The @code{syntax-table} property overrides what the syntax table says
|
|
about this particular character. @xref{Syntax Properties}.
|
|
|
|
@cindex read-only character
|
|
@kindex read-only @r{(text property)}
|
|
@item read-only
|
|
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,
|
|
@code{text-read-only}. If the property value is a string, that string
|
|
is used as the error message.
|
|
|
|
Insertion next to a read-only character is an error if inserting
|
|
ordinary text there would inherit the @code{read-only} property due to
|
|
stickiness. Thus, you can control permission to insert next to
|
|
read-only text by controlling the stickiness. @xref{Sticky Properties}.
|
|
|
|
Since changing properties counts as modifying the buffer, it is not
|
|
possible to remove a @code{read-only} property unless you know the
|
|
special trick: bind @code{inhibit-read-only} to a non-@code{nil} value
|
|
and then remove the property. @xref{Read Only Buffers}.
|
|
|
|
@kindex inhibit-read-only @r{(text property)}
|
|
@item inhibit-read-only
|
|
Characters that have the property @code{inhibit-read-only} can be
|
|
edited even in read-only buffers. @xref{Read Only Buffers}.
|
|
|
|
@kindex invisible @r{(text property)}
|
|
@item invisible
|
|
A non-@code{nil} @code{invisible} property can make a character invisible
|
|
on the screen. @xref{Invisible Text}, for details.
|
|
|
|
@item inhibit-isearch
|
|
@kindex inhibit-isearch @r{(text property)}
|
|
A non-@code{nil} @code{inhibit-isearch} property will make isearch
|
|
skip the text.
|
|
|
|
@kindex intangible @r{(text property)}
|
|
@item intangible
|
|
If a group of consecutive characters have equal and non-@code{nil}
|
|
@code{intangible} properties, then you cannot place point between them.
|
|
If you try to move point forward into the group, point actually moves to
|
|
the end of the group. If you try to move point backward into the group,
|
|
point actually moves to the start of the group.
|
|
|
|
If consecutive characters have unequal non-@code{nil}
|
|
@code{intangible} properties, they belong to separate groups; each
|
|
group is separately treated as described above.
|
|
|
|
When the variable @code{inhibit-point-motion-hooks} is non-@code{nil}
|
|
(as it is by default), the @code{intangible} property is ignored.
|
|
|
|
Beware: this property operates at a very low level, and affects a lot of code
|
|
in unexpected ways. So use it with extreme caution. A common misuse is to put
|
|
an intangible property on invisible text, which is actually unnecessary since
|
|
the command loop will move point outside of the invisible text at the end of
|
|
each command anyway. @xref{Adjusting Point}. For these reasons, this
|
|
property is obsolete; use the @code{cursor-intangible} property instead.
|
|
|
|
@kindex cursor-intangible @r{(text property)}
|
|
@findex cursor-intangible-mode
|
|
@cindex rear-nonsticky, and cursor-intangible property
|
|
@item cursor-intangible
|
|
When the minor mode @code{cursor-intangible-mode} is turned on, point
|
|
is moved away from any position that has a non-@code{nil}
|
|
@code{cursor-intangible} property, just before redisplay happens.
|
|
Note that ``stickiness'' of the property (@pxref{Sticky Properties})
|
|
is taken into account when computing allowed cursor positions, so (for
|
|
instance) to insert a stretch of five @samp{x} characters into which
|
|
the cursor can't enter, you should do something like:
|
|
|
|
@lisp
|
|
(insert
|
|
(propertize "xxxx" 'cursor-intangible t)
|
|
(propertize "x" 'cursor-intangible t 'rear-nonsticky t))
|
|
@end lisp
|
|
|
|
@vindex cursor-sensor-inhibit
|
|
When the variable @code{cursor-sensor-inhibit} is non-@code{nil}, the
|
|
@code{cursor-intangible} property and the
|
|
@code{cursor-sensor-functions} property (described below) are ignored.
|
|
|
|
@kindex field @r{(text property)}
|
|
@item field
|
|
Consecutive characters with the same @code{field} property constitute a
|
|
@dfn{field}. Some motion functions including @code{forward-word} and
|
|
@code{beginning-of-line} stop moving at a field boundary.
|
|
@xref{Fields}.
|
|
|
|
@kindex cursor @r{(text property)}
|
|
@item cursor
|
|
Normally, the cursor is displayed at the beginning or the end of any
|
|
overlay and text property strings that ``hide'' (i.e., are displayed
|
|
instead of) the current buffer position. You can instead tell Emacs
|
|
to place the cursor on any desired character of these strings by
|
|
giving that character a non-@code{nil} @code{cursor} text property.
|
|
In addition, if the value of the @code{cursor} property is an integer,
|
|
it specifies the number of buffer's character positions, starting with
|
|
the position where the overlay or the @code{display} property begins,
|
|
for which the cursor should be displayed on that character.
|
|
Specifically, if the value of the @code{cursor} property of a
|
|
character is the number @var{n}, the cursor will be displayed on this
|
|
character for any buffer position in the range
|
|
@code{[@var{ovpos}..@var{ovpos}+@var{n})}, where @var{ovpos} is the
|
|
overlay's starting position given by @code{overlay-start}
|
|
(@pxref{Managing Overlays}), or the position where the @code{display}
|
|
text property begins in the buffer.
|
|
|
|
In other words, the string character with the @code{cursor} property
|
|
of any non-@code{nil} value is the character where to display the
|
|
cursor when the overlay or display string make point not visible on
|
|
display. The value of the property says for which buffer positions to
|
|
display the cursor there. If the value is an integer @var{n}, the
|
|
cursor is displayed there when point is anywhere between the beginning
|
|
of the overlay or @code{display} property and @var{n} positions after
|
|
that. If the value is anything else and non-@code{nil}, the cursor is
|
|
displayed there only when point is at the buffer position that is the
|
|
beginning of the @code{display} property, or at @code{overlay-start}
|
|
if that position is not visible on display. Note that an integer
|
|
value of the @code{cursor} property could mean that the cursor is
|
|
displayed on that character even when point is visible on display.
|
|
|
|
One subtlety of this property is that it doesn't work to put this
|
|
property on a newline character that is part of a display or overlay
|
|
string. That's because the newline doesn't have a graphic
|
|
representation on the screen for Emacs to find when it looks for a
|
|
character on display with that @code{cursor} property.
|
|
|
|
@cindex cursor position for @code{display} properties and overlays
|
|
When the buffer has many overlay strings (e.g., @pxref{Overlay
|
|
Properties, before-string}) that conceal some of the buffer text or
|
|
@code{display} properties that are strings, it is a good idea to use
|
|
the @code{cursor} property on these strings to cue the Emacs display
|
|
about the places where to put the cursor while traversing these
|
|
strings. This directly communicates to the display engine where the
|
|
Lisp program wants to put the cursor, or where the user would expect
|
|
the cursor, when point is located on some buffer position that is
|
|
``covered'' by the display or overlay string.
|
|
|
|
@kindex pointer @r{(text property)}
|
|
@item pointer
|
|
This specifies a specific pointer shape when the mouse pointer is over
|
|
this text or image. @xref{Pointer Shape}, for possible pointer
|
|
shapes.
|
|
|
|
@kindex line-spacing @r{(text property)}
|
|
@item line-spacing
|
|
A newline can have a @code{line-spacing} text or overlay property that
|
|
controls the height of the display line ending with that newline. The
|
|
property value overrides the default frame line spacing and the buffer
|
|
local @code{line-spacing} variable. @xref{Line Height}.
|
|
|
|
@kindex line-height @r{(text property)}
|
|
@item line-height
|
|
A newline can have a @code{line-height} text or overlay property that
|
|
controls the total height of the display line ending in that newline.
|
|
@xref{Line Height}.
|
|
|
|
@item wrap-prefix
|
|
If a region of text has a @code{wrap-prefix} property, the prefix it
|
|
defines will be added at display time to the beginning of every
|
|
continuation line due to text wrapping (so if lines are truncated, the
|
|
wrap-prefix is never used). The property value may be a string or an
|
|
image (@pxref{Other Display Specs}), or a stretch of whitespace such as
|
|
specified by the @code{:width} or @code{:align-to} display properties
|
|
(@pxref{Specified Space}). Note that to have its effect, the
|
|
@code{wrap-prefix} property must be set on the entire region of text,
|
|
starting from the first character of the first line of that text and up
|
|
to the last character of the last line; otherwise, breaking the text
|
|
into lines in a different way might fail to display the prefix, because
|
|
the display engine checks for this property only immediately after
|
|
continuing a line.
|
|
|
|
A wrap-prefix may also be specified for an entire buffer using the
|
|
@code{wrap-prefix} buffer-local variable (however, a
|
|
@code{wrap-prefix} text-property takes precedence over the value of
|
|
the @code{wrap-prefix} variable). @xref{Truncation}.
|
|
|
|
@item line-prefix
|
|
If a region of text has a @code{line-prefix} property, the prefix it
|
|
defines will be added at display time to the beginning of every
|
|
non-continuation line. The property value may be a string or an image
|
|
(@pxref{Other Display Specs}), or a stretch of whitespace such as
|
|
specified by the @code{:width} or @code{:align-to} display properties
|
|
(@pxref{Specified Space}). Note that to have its effect, the
|
|
@code{line-prefix} property must be set on the entire region of text,
|
|
starting from the first character of the first line of that text and up
|
|
to the last character of the last line; otherwise, breaking the text
|
|
into lines in a different way might fail to display the prefix, because
|
|
the display engine checks for this property only when starting a new
|
|
line.
|
|
|
|
A line-prefix may also be specified for an entire buffer using the
|
|
@code{line-prefix} buffer-local variable (however, a
|
|
@code{line-prefix} text-property takes precedence over the value of
|
|
the @code{line-prefix} variable). @xref{Truncation}.
|
|
|
|
@cindex change hooks for a character
|
|
@cindex hooks for changing a character
|
|
@kindex modification-hooks @r{(text property)}
|
|
@item modification-hooks
|
|
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 before the actual modification. 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.
|
|
Furthermore, insertion will not modify any existing character, so this
|
|
hook will only be run when removing some characters, replacing them
|
|
with others, or changing their text-properties.
|
|
|
|
Unlike with other similar hooks, when Emacs calls these functions,
|
|
@code{inhibit-modification-hooks} does @emph{not} get bound to
|
|
non-@code{nil}. If the functions modify the buffer, you should
|
|
consider binding this variable to non-@code{nil} to prevent any buffer
|
|
changes running the change hooks. Otherwise, you must be prepared for
|
|
recursive calls. @xref{Change Hooks}.
|
|
|
|
Overlays also support the @code{modification-hooks} property, but the
|
|
details are somewhat different (@pxref{Overlay Properties}).
|
|
|
|
@kindex insert-in-front-hooks @r{(text property)}
|
|
@kindex insert-behind-hooks @r{(text property)}
|
|
@item insert-in-front-hooks
|
|
@itemx insert-behind-hooks
|
|
The operation of inserting text in a buffer also calls the functions
|
|
listed in the @code{insert-in-front-hooks} property of the following
|
|
character and in the @code{insert-behind-hooks} property of the
|
|
preceding character. These functions receive two arguments, the
|
|
beginning and end of the inserted text. The functions are called
|
|
@emph{after} the actual insertion takes place.
|
|
|
|
When these functions are called, @code{inhibit-modification-hooks} is
|
|
bound to non-@code{nil}. If the functions modify the buffer, you
|
|
might want to bind @code{inhibit-modification-hooks} to @code{nil}, so
|
|
as to cause the change hooks to run for these modifications. However,
|
|
doing this may call your own change hook recursively, so be sure to
|
|
prepare for that.
|
|
|
|
See also @ref{Change Hooks}, for other hooks that are called
|
|
when you change text in a buffer.
|
|
|
|
@cindex hooks for motion of point
|
|
@kindex point-entered @r{(text property)}
|
|
@kindex point-left @r{(text property)}
|
|
@item point-entered
|
|
@itemx point-left
|
|
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). In any case, all the
|
|
@code{point-left} functions are called first, followed by all the
|
|
@code{point-entered} functions.
|
|
|
|
It is possible to use @code{char-after} to examine characters at various
|
|
buffer positions without moving point to those positions. Only an
|
|
actual change in the value of point runs these hook functions.
|
|
|
|
The variable @code{inhibit-point-motion-hooks} by default inhibits
|
|
running the @code{point-left} and @code{point-entered} hooks, see
|
|
@ref{Inhibit point motion hooks}.
|
|
|
|
These properties are obsolete; please use
|
|
@code{cursor-sensor-functions} instead.
|
|
|
|
@kindex cursor-sensor-functions @r{(text property)}
|
|
@findex cursor-sensor-mode
|
|
@item cursor-sensor-functions
|
|
This special property records a list of functions that react to cursor
|
|
motion. Each function in the list is called, just before redisplay,
|
|
with 3 arguments: the affected window, the previous known position of
|
|
the cursor, and one of the symbols @code{entered} or @code{left},
|
|
depending on whether the cursor is entering the text that has this
|
|
property or leaving it. The functions are called only when the minor
|
|
mode @code{cursor-sensor-mode} is turned on.
|
|
|
|
When the variable @code{cursor-sensor-inhibit} is non-@code{nil}, the
|
|
@code{cursor-sensor-functions} property is ignored.
|
|
|
|
@kindex composition @r{(text property)}
|
|
@item composition
|
|
This text property is used to display a sequence of characters as a
|
|
single glyph composed from components. But the value of the property
|
|
itself is completely internal to Emacs and should not be manipulated
|
|
directly by, for instance, @code{put-text-property}.
|
|
|
|
@kindex minibuffer-message @r{(text property)}
|
|
@item minibuffer-message
|
|
This text property tells where to display temporary messages in an
|
|
active minibuffer. Specifically, the first character of the
|
|
minibuffer text which has this property will have the temporary
|
|
message displayed before it. The default is to display temporary
|
|
messages at the end of the minibuffer text. This text property is
|
|
used by the function that is the default value of
|
|
@code{set-message-function} (@pxref{Displaying Messages}).
|
|
|
|
@kindex display-line-numbers-disable @r{(text property)}
|
|
@item display-line-numbers-disable
|
|
This text property prevents display of line numbers (@pxref{Display
|
|
Custom, display-line-numbers,, emacs, The GNU Emacs Manual}) for the
|
|
text which has this property.
|
|
|
|
@end table
|
|
|
|
@defvar inhibit-point-motion-hooks
|
|
@anchor{Inhibit point motion hooks} When this obsolete variable is
|
|
non-@code{nil}, @code{point-left} and @code{point-entered} hooks are
|
|
not run, and the @code{intangible} property has no effect. Do not set
|
|
this variable globally; bind it with @code{let}. Since the affected
|
|
properties are obsolete, this variable's default value is @code{t}, to
|
|
effectively disable them.
|
|
@end defvar
|
|
|
|
@defvar show-help-function
|
|
@anchor{Help display} If this variable is non-@code{nil}, it specifies
|
|
a function called to display help strings. These may be
|
|
@code{help-echo} properties, menu help strings (@pxref{Simple Menu
|
|
Items}, @pxref{Extended Menu Items}), or tool bar help strings
|
|
(@pxref{Tool Bar}). The specified function is called with one
|
|
argument, the help string to display, which is passed through
|
|
@code{substitute-command-keys} before being given to the function,
|
|
unless the help string has a non-@code{nil}
|
|
@code{help-echo-inhibit-substitution} property on its first character; see
|
|
@ref{Keys in Documentation}. See the code of Tooltip mode
|
|
(@pxref{Tooltips,,, emacs, The GNU Emacs Manual}) for an example of a
|
|
mode that uses @code{show-help-function}.
|
|
@end defvar
|
|
|
|
@defvar face-filters-always-match
|
|
If this variable is non-@code{nil}, face filters that specify
|
|
attributes applied only when certain conditions are met will be deemed
|
|
to match always.
|
|
@end defvar
|
|
|
|
@node Format Properties
|
|
@subsection Formatted Text Properties
|
|
|
|
These text properties affect the behavior of the fill commands. They
|
|
are used for representing formatted text. @xref{Filling}, and
|
|
@ref{Margins}.
|
|
|
|
@table @code
|
|
@item hard
|
|
If a newline character has this property, it is a ``hard'' newline.
|
|
The fill commands do not alter hard newlines and do not move words
|
|
across them. However, this property takes effect only if the
|
|
@code{use-hard-newlines} minor mode is enabled. @xref{Hard and Soft
|
|
Newlines,, Hard and Soft Newlines, emacs, The GNU Emacs Manual}.
|
|
|
|
@item right-margin
|
|
This property specifies an extra right margin for filling this part of the
|
|
text.
|
|
|
|
@item left-margin
|
|
This property specifies an extra left margin for filling this part of the
|
|
text.
|
|
|
|
@item justification
|
|
This property specifies the style of justification for filling this part
|
|
of the text.
|
|
@end table
|
|
|
|
@node Sticky Properties
|
|
@subsection Stickiness of Text Properties
|
|
@cindex sticky text properties
|
|
@cindex inheritance, text property
|
|
|
|
Self-inserting characters, the ones that get inserted into a buffer
|
|
when the user types them (@pxref{Commands for Insertion}), normally
|
|
take on the same properties as the preceding character. This is
|
|
called @dfn{inheritance} of properties.
|
|
|
|
By contrast, a Lisp program can do insertion with inheritance or without,
|
|
depending on the choice of insertion primitive. The ordinary text
|
|
insertion functions, such as @code{insert}, do not inherit any
|
|
properties. They insert text with precisely the properties of the
|
|
string being inserted, and no others. This is correct for programs
|
|
that copy text from one context to another---for example, into or out
|
|
of the kill ring. To insert with inheritance, use the special
|
|
primitives described in this section. Self-inserting characters
|
|
inherit properties because they work using these primitives.
|
|
|
|
@cindex front-sticky text property
|
|
@cindex rear-nonsticky text property
|
|
When you do insertion with inheritance, @emph{which} properties are
|
|
inherited, and from where, depends on which properties are @dfn{sticky}.
|
|
Insertion after a character inherits those of its properties that are
|
|
@dfn{rear-sticky}. Insertion before a character inherits those of its
|
|
properties that are @dfn{front-sticky}. When both sides offer different
|
|
sticky values for the same property, the previous character's value
|
|
takes precedence.
|
|
|
|
By default, a text property is rear-sticky but not front-sticky; thus,
|
|
the default is to inherit all the properties of the preceding character,
|
|
and nothing from the following character.
|
|
|
|
You can control the stickiness of various text properties with two
|
|
specific text properties, @code{front-sticky} and @code{rear-nonsticky},
|
|
and with the variable @code{text-property-default-nonsticky}. You can
|
|
use the variable to specify a different default for a given property.
|
|
You can use those two text properties to make any specific properties
|
|
sticky or nonsticky in any particular part of the text.
|
|
|
|
If a character's @code{front-sticky} property is @code{t}, then all
|
|
its properties are front-sticky. If the @code{front-sticky} property is
|
|
a list, then the sticky properties of the character are those whose
|
|
names are in the list. For example, if a character has a
|
|
@code{front-sticky} property whose value is @code{(face read-only)},
|
|
then insertion before the character can inherit its @code{face} property
|
|
and its @code{read-only} property, but no others.
|
|
|
|
The @code{rear-nonsticky} property works the opposite way. Most
|
|
properties are rear-sticky by default, so the @code{rear-nonsticky}
|
|
property says which properties are @emph{not} rear-sticky. If a
|
|
character's @code{rear-nonsticky} property is @code{t}, then none of its
|
|
properties are rear-sticky. If the @code{rear-nonsticky} property is a
|
|
list, properties are rear-sticky @emph{unless} their names are in the
|
|
list.
|
|
|
|
@defvar text-property-default-nonsticky
|
|
This variable holds an alist which defines the default rear-stickiness
|
|
of various text properties. Each element has the form
|
|
@code{(@var{property} . @var{nonstickiness})}, and it defines the
|
|
stickiness of a particular text property, @var{property}.
|
|
|
|
If @var{nonstickiness} is non-@code{nil}, this means that the property
|
|
@var{property} is rear-nonsticky by default. Since all properties are
|
|
front-nonsticky by default, this makes @var{property} nonsticky in both
|
|
directions by default.
|
|
|
|
The text properties @code{front-sticky} and @code{rear-nonsticky}, when
|
|
used, take precedence over the default @var{nonstickiness} specified in
|
|
@code{text-property-default-nonsticky}.
|
|
@end defvar
|
|
|
|
Here are the functions that insert text with inheritance of properties:
|
|
|
|
@defun insert-and-inherit &rest strings
|
|
Insert the strings @var{strings}, just like the function @code{insert},
|
|
but inherit any sticky properties from the adjoining text.
|
|
@end defun
|
|
|
|
@defun insert-before-markers-and-inherit &rest strings
|
|
Insert the strings @var{strings}, just like the function
|
|
@code{insert-before-markers}, but inherit any sticky properties from the
|
|
adjoining text.
|
|
@end defun
|
|
|
|
@xref{Insertion}, for the ordinary insertion functions which do not
|
|
inherit.
|
|
|
|
@node Lazy Properties
|
|
@subsection Lazy Computation of Text Properties
|
|
|
|
Instead of computing text properties for all the text in the buffer,
|
|
you can arrange to compute the text properties for parts of the text
|
|
when and if something depends on them.
|
|
|
|
The primitive that extracts text from the buffer along with its
|
|
properties is @code{buffer-substring}. Before examining the properties,
|
|
this function runs the abnormal hook @code{buffer-access-fontify-functions}.
|
|
|
|
@defvar buffer-access-fontify-functions
|
|
This variable holds a list of functions for computing text properties.
|
|
Before @code{buffer-substring} copies the text and text properties for a
|
|
portion of the buffer, it calls all the functions in this list. Each of
|
|
the functions receives two arguments that specify the range of the
|
|
buffer being accessed. (The buffer itself is always the current
|
|
buffer.)
|
|
@end defvar
|
|
|
|
The function @code{buffer-substring-no-properties} does not call these
|
|
functions, since it ignores text properties anyway.
|
|
|
|
In order to prevent the hook functions from being called more than
|
|
once for the same part of the buffer, you can use the variable
|
|
@code{buffer-access-fontified-property}.
|
|
|
|
@defvar buffer-access-fontified-property
|
|
If this variable's value is non-@code{nil}, it is a symbol which is used
|
|
as a text property name. A non-@code{nil} value for that text property
|
|
means the other text properties for this character have already been
|
|
computed.
|
|
|
|
If all the characters in the range specified for @code{buffer-substring}
|
|
have a non-@code{nil} value for this property, @code{buffer-substring}
|
|
does not call the @code{buffer-access-fontify-functions} functions. It
|
|
assumes these characters already have the right text properties, and
|
|
just copies the properties they already have.
|
|
|
|
The normal way to use this feature is that the
|
|
@code{buffer-access-fontify-functions} functions add this property, as
|
|
well as others, to the characters they operate on. That way, they avoid
|
|
being called over and over for the same text.
|
|
@end defvar
|
|
|
|
@node Clickable Text
|
|
@subsection Defining Clickable Text
|
|
@cindex clickable text
|
|
@cindex follow links
|
|
@cindex mouse-1
|
|
|
|
@dfn{Clickable text} is text that can be clicked, with either the
|
|
mouse or via a keyboard command, to produce some result. Many major
|
|
modes use clickable text to implement textual hyper-links, or
|
|
@dfn{links} for short.
|
|
|
|
The easiest way to insert and manipulate links is to use the
|
|
@code{button} package. @xref{Buttons}. In this section, we will
|
|
explain how to manually set up clickable text in a buffer, using text
|
|
properties. For simplicity, we will refer to the clickable text as a
|
|
@dfn{link}.
|
|
|
|
Implementing a link involves three separate steps: (1) indicating
|
|
clickability when the mouse moves over the link; (2) making @key{RET}
|
|
or @kbd{mouse-2} on that link do something; and (3) setting up a
|
|
@code{follow-link} condition so that the link obeys
|
|
@code{mouse-1-click-follows-link}.
|
|
|
|
To indicate clickability, add the @code{mouse-face} text property to
|
|
the text of the link; then Emacs will highlight the link when the
|
|
mouse moves over it. In addition, you should define a tooltip or echo
|
|
area message, using the @code{help-echo} text property. @xref{Special
|
|
Properties}. For instance, here is how Dired indicates that file
|
|
names are clickable:
|
|
|
|
@smallexample
|
|
(if (dired-move-to-filename)
|
|
(add-text-properties
|
|
(point)
|
|
(save-excursion
|
|
(dired-move-to-end-of-filename)
|
|
(point))
|
|
'(mouse-face highlight
|
|
help-echo "mouse-2: visit this file in other window")))
|
|
@end smallexample
|
|
|
|
To make the link clickable, bind @key{RET} and @kbd{mouse-2} to
|
|
commands that perform the desired action. Each command should check
|
|
to see whether it was called on a link, and act accordingly. For
|
|
instance, Dired's major mode keymap binds @kbd{mouse-2} to the
|
|
following command:
|
|
|
|
@smallexample
|
|
(defun dired-mouse-find-file-other-window (event)
|
|
"In Dired, visit the file or directory name you click on."
|
|
(interactive "e")
|
|
(let ((window (posn-window (event-end event)))
|
|
(pos (posn-point (event-end event)))
|
|
file)
|
|
(if (not (windowp window))
|
|
(error "No file chosen"))
|
|
(with-current-buffer (window-buffer window)
|
|
(goto-char pos)
|
|
(setq file (dired-get-file-for-visit)))
|
|
(if (file-directory-p file)
|
|
(or (and (cdr dired-subdir-alist)
|
|
(dired-goto-subdir file))
|
|
(progn
|
|
(select-window window)
|
|
(dired-other-window file)))
|
|
(select-window window)
|
|
(find-file-other-window (file-name-sans-versions file t)))))
|
|
@end smallexample
|
|
|
|
@noindent
|
|
This command uses the functions @code{posn-window} and
|
|
@code{posn-point} to determine where the click occurred, and
|
|
@code{dired-get-file-for-visit} to determine which file to visit.
|
|
|
|
Instead of binding the mouse command in a major mode keymap, you can
|
|
bind it within the link text, using the @code{keymap} text property
|
|
(@pxref{Special Properties}). For instance:
|
|
|
|
@example
|
|
(let ((map (make-sparse-keymap)))
|
|
(define-key map [mouse-2] 'operate-this-button)
|
|
(put-text-property link-start link-end 'keymap map))
|
|
@end example
|
|
|
|
@noindent
|
|
With this method, you can easily define different commands for
|
|
different links. Furthermore, the global definition of @key{RET} and
|
|
@kbd{mouse-2} remain available for the rest of the text in the buffer.
|
|
|
|
@vindex mouse-1-click-follows-link
|
|
The basic Emacs command for clicking on links is @kbd{mouse-2}.
|
|
However, for compatibility with other graphical applications, Emacs
|
|
also recognizes @kbd{mouse-1} clicks on links, provided the user
|
|
clicks on the link quickly without moving the mouse. This behavior is
|
|
controlled by the user option @code{mouse-1-click-follows-link}.
|
|
@xref{Mouse References,,, emacs, The GNU Emacs Manual}.
|
|
|
|
@kindex follow-link @r{(text or overlay property)}
|
|
To set up the link so that it obeys
|
|
@code{mouse-1-click-follows-link}, you must either (1) apply a
|
|
@code{follow-link} text or overlay property to the link text, or (2)
|
|
bind the @code{follow-link} event to a keymap (which can be a major
|
|
mode keymap or a local keymap specified via the @code{keymap} text
|
|
property). The value of the @code{follow-link} property, or the
|
|
binding for the @code{follow-link} event, acts as a condition for
|
|
the link action. This condition tells Emacs two things: the
|
|
circumstances under which a @kbd{mouse-1} click should be regarded as
|
|
occurring inside the link, and how to compute an action code
|
|
that says what to translate the @kbd{mouse-1} click into. The link
|
|
action condition can be one of the following:
|
|
|
|
@table @asis
|
|
@item @code{mouse-face}
|
|
If the condition is the symbol @code{mouse-face}, a position is inside
|
|
a link if there is a non-@code{nil} @code{mouse-face} property at that
|
|
position. The action code is always @code{t}.
|
|
|
|
For example, here is how Info mode handles @key{mouse-1}:
|
|
|
|
@smallexample
|
|
(keymap-set Info-mode-map "<follow-link>" 'mouse-face)
|
|
@end smallexample
|
|
|
|
@item a function
|
|
If the condition is a function, @var{func}, then a position @var{pos}
|
|
is inside a link if @code{(@var{func} @var{pos})} evaluates to
|
|
non-@code{nil}. The value returned by @var{func} serves as the action
|
|
code.
|
|
|
|
For example, here is how pcvs enables @kbd{mouse-1} to follow links on
|
|
file names only:
|
|
|
|
@smallexample
|
|
(keymap-set map "<follow-link>"
|
|
(lambda (pos)
|
|
(eq (get-char-property pos 'face) 'cvs-filename-face)))
|
|
@end smallexample
|
|
|
|
@item anything else
|
|
If the condition value is anything else, then the position is inside a
|
|
link and the condition itself is the action code. Clearly, you should
|
|
specify this kind of condition only when applying the condition via a
|
|
text or overlay property on the link text (so that it does not apply
|
|
to the entire buffer).
|
|
@end table
|
|
|
|
@noindent
|
|
The action code tells @kbd{mouse-1} how to follow the link:
|
|
|
|
@table @asis
|
|
@item a string or vector
|
|
If the action code is a string or vector, the @kbd{mouse-1} event is
|
|
translated into the first element of the string or vector; i.e., the
|
|
action of the @kbd{mouse-1} click is the local or global binding of
|
|
that character or symbol. Thus, if the action code is @code{"foo"},
|
|
@kbd{mouse-1} translates into @kbd{f}. If it is @code{[foo]},
|
|
@kbd{mouse-1} translates into @key{foo}.
|
|
|
|
@item anything else
|
|
For any other non-@code{nil} action code, the @kbd{mouse-1} event is
|
|
translated into a @kbd{mouse-2} event at the same position.
|
|
@end table
|
|
|
|
To define @kbd{mouse-1} to activate a button defined with
|
|
@code{define-button-type}, give the button a @code{follow-link}
|
|
property. The property value should be a link action condition, as
|
|
described above. @xref{Buttons}. For example, here is how Help mode
|
|
handles @kbd{mouse-1}:
|
|
|
|
@smallexample
|
|
(define-button-type 'help-xref
|
|
'follow-link t
|
|
'action #'help-button-action)
|
|
@end smallexample
|
|
|
|
To define @kbd{mouse-1} on a widget defined with
|
|
@code{define-widget}, give the widget a @code{:follow-link} property.
|
|
The property value should be a link action condition, as described
|
|
above. For example, here is how the @code{link} widget specifies that
|
|
a @key{mouse-1} click shall be translated to @key{RET}:
|
|
|
|
@smallexample
|
|
(define-widget 'link 'item
|
|
"An embedded link."
|
|
:button-prefix 'widget-link-prefix
|
|
:button-suffix 'widget-link-suffix
|
|
:follow-link "\C-m"
|
|
:help-echo "Follow the link."
|
|
:format "%[%t%]")
|
|
@end smallexample
|
|
|
|
@defun mouse-on-link-p pos
|
|
This function returns non-@code{nil} if position @var{pos} in the
|
|
current buffer is on a link. @var{pos} can also be a mouse event
|
|
location, as returned by @code{event-start} (@pxref{Accessing Mouse}).
|
|
@end defun
|
|
|
|
@node Fields
|
|
@subsection Defining and Using Fields
|
|
@cindex fields
|
|
|
|
A field is a range of consecutive characters in the buffer that are
|
|
identified by having the same value (comparing with @code{eq}) of the
|
|
@code{field} property (either a text-property or an overlay property).
|
|
This section describes special functions that are available for
|
|
operating on fields.
|
|
|
|
You specify a field with a buffer position, @var{pos}. We think of
|
|
each field as containing a range of buffer positions, so the position
|
|
you specify stands for the field containing that position.
|
|
|
|
When the characters before and after @var{pos} are part of the same
|
|
field, there is no doubt which field contains @var{pos}: the one those
|
|
characters both belong to. When @var{pos} is at a boundary between
|
|
fields, which field it belongs to depends on the stickiness of the
|
|
@code{field} properties of the two surrounding characters (@pxref{Sticky
|
|
Properties}). The field whose property would be inherited by text
|
|
inserted at @var{pos} is the field that contains @var{pos}.
|
|
|
|
There is an anomalous case where newly inserted text at @var{pos}
|
|
would not inherit the @code{field} property from either side. This
|
|
happens if the previous character's @code{field} property is not
|
|
rear-sticky, and the following character's @code{field} property is not
|
|
front-sticky. In this case, @var{pos} belongs to neither the preceding
|
|
field nor the following field; the field functions treat it as belonging
|
|
to an empty field whose beginning and end are both at @var{pos}.
|
|
|
|
In all of these functions, if @var{pos} is omitted or @code{nil}, the
|
|
value of point is used by default. If narrowing is in effect, then
|
|
@var{pos} should fall within the accessible portion. @xref{Narrowing}.
|
|
|
|
@defun field-beginning &optional pos escape-from-edge limit
|
|
This function returns the beginning of the field specified by @var{pos}.
|
|
|
|
If @var{pos} is at the beginning of its field, and
|
|
@var{escape-from-edge} is non-@code{nil}, then the return value is
|
|
always the beginning of the preceding field that @emph{ends} at @var{pos},
|
|
regardless of the stickiness of the @code{field} properties around
|
|
@var{pos}.
|
|
|
|
If @var{limit} is non-@code{nil}, it is a buffer position; if the
|
|
beginning of the field is before @var{limit}, then @var{limit} will be
|
|
returned instead.
|
|
@end defun
|
|
|
|
@defun field-end &optional pos escape-from-edge limit
|
|
This function returns the end of the field specified by @var{pos}.
|
|
|
|
If @var{pos} is at the end of its field, and @var{escape-from-edge} is
|
|
non-@code{nil}, then the return value is always the end of the following
|
|
field that @emph{begins} at @var{pos}, regardless of the stickiness of
|
|
the @code{field} properties around @var{pos}.
|
|
|
|
If @var{limit} is non-@code{nil}, it is a buffer position; if the end
|
|
of the field is after @var{limit}, then @var{limit} will be returned
|
|
instead.
|
|
@end defun
|
|
|
|
@defun field-string &optional pos
|
|
This function returns the contents of the field specified by @var{pos},
|
|
as a string.
|
|
@end defun
|
|
|
|
@defun field-string-no-properties &optional pos
|
|
This function returns the contents of the field specified by @var{pos},
|
|
as a string, discarding text properties.
|
|
@end defun
|
|
|
|
@defun delete-field &optional pos
|
|
This function deletes the text of the field specified by @var{pos}.
|
|
@end defun
|
|
|
|
@defun constrain-to-field new-pos old-pos &optional escape-from-edge only-in-line inhibit-capture-property
|
|
This function constrains @var{new-pos} to the field that
|
|
@var{old-pos} belongs to---in other words, it returns the position
|
|
closest to @var{new-pos} that is in the same field as @var{old-pos}.
|
|
|
|
If @var{new-pos} is @code{nil}, then @code{constrain-to-field} uses
|
|
the value of point instead, and moves point to the resulting position
|
|
in addition to returning that position.
|
|
|
|
If @var{old-pos} is at the boundary of two fields, then the acceptable
|
|
final positions depend on the argument @var{escape-from-edge}. If
|
|
@var{escape-from-edge} is @code{nil}, then @var{new-pos} must be in
|
|
the field whose @code{field} property equals what new characters
|
|
inserted at @var{old-pos} would inherit. (This depends on the
|
|
stickiness of the @code{field} property for the characters before and
|
|
after @var{old-pos}.) If @var{escape-from-edge} is non-@code{nil},
|
|
@var{new-pos} can be anywhere in the two adjacent fields.
|
|
Additionally, if two fields are separated by another field with the
|
|
special value @code{boundary}, then any point within this special
|
|
field is also considered to be on the boundary.
|
|
|
|
Commands like @kbd{C-a} with no argument, that normally move backward
|
|
to a specific kind of location and stay there once there, probably
|
|
should specify @code{nil} for @var{escape-from-edge}. Other motion
|
|
commands that check fields should probably pass @code{t}.
|
|
|
|
If the optional argument @var{only-in-line} is non-@code{nil}, and
|
|
constraining @var{new-pos} in the usual way would move it to a different
|
|
line, @var{new-pos} is returned unconstrained. This used in commands
|
|
that move by line, such as @code{next-line} and
|
|
@code{beginning-of-line}, so that they respect field boundaries only in
|
|
the case where they can still move to the right line.
|
|
|
|
If the optional argument @var{inhibit-capture-property} is
|
|
non-@code{nil}, and @var{old-pos} has a non-@code{nil} property of that
|
|
name, then any field boundaries are ignored.
|
|
|
|
You can cause @code{constrain-to-field} to ignore all field boundaries
|
|
(and so never constrain anything) by binding the variable
|
|
@code{inhibit-field-text-motion} to a non-@code{nil} value.
|
|
@end defun
|
|
|
|
@node Not Intervals
|
|
@subsection Why Text Properties are not Intervals
|
|
@cindex intervals
|
|
|
|
Some editors that support adding attributes to text in the buffer do
|
|
so by letting the user specify intervals within the text, and adding
|
|
the properties to the intervals. Those editors permit the user or the
|
|
programmer to determine where individual intervals start and end. We
|
|
deliberately provided a different sort of interface in Emacs Lisp to
|
|
avoid certain paradoxical behavior associated with text modification.
|
|
|
|
If the actual subdivision into intervals is meaningful, that means you
|
|
can distinguish between a buffer that is just one interval with a
|
|
certain property, and a buffer containing the same text subdivided into
|
|
two intervals, both of which have that property.
|
|
|
|
Suppose you take the buffer with just one interval and kill part of
|
|
the text. The text remaining in the buffer is one interval, and the
|
|
copy in the kill ring (and the undo list) becomes a separate interval.
|
|
Then if you yank back the killed text, you get two intervals with the
|
|
same properties. Thus, editing does not preserve the distinction
|
|
between one interval and two.
|
|
|
|
Suppose we attempt to fix this problem by coalescing the two intervals when
|
|
the text is inserted. That works fine if the buffer originally was a
|
|
single interval. But suppose instead that we have two adjacent
|
|
intervals with the same properties, and we kill the text of one interval
|
|
and yank it back. The same interval-coalescence feature that rescues
|
|
the other case causes trouble in this one: after yanking, we have just
|
|
one interval. Once again, editing does not preserve the distinction
|
|
between one interval and two.
|
|
|
|
Insertion of text at the border between intervals also raises
|
|
questions that have no satisfactory answer.
|
|
|
|
However, it is easy to arrange for editing to behave consistently
|
|
for questions of the form, ``What are the properties of text at this
|
|
buffer or string position?'' So we have decided these are the only
|
|
questions that make sense; we have not implemented asking questions
|
|
about where intervals start or end.
|
|
|
|
In practice, you can usually use the text property search functions in
|
|
place of explicit interval boundaries. You can think of them as finding
|
|
the boundaries of intervals, assuming that intervals are always
|
|
coalesced whenever possible. @xref{Property Search}.
|
|
|
|
Emacs also provides explicit intervals as a presentation feature; see
|
|
@ref{Overlays}.
|
|
|
|
@node Substitution
|
|
@section Substituting for a Character Code
|
|
@cindex replace characters in region
|
|
@cindex substitute characters
|
|
|
|
The following functions replace characters within a specified region
|
|
based on their character codes.
|
|
|
|
@defun subst-char-in-region start end old-char new-char &optional noundo
|
|
@cindex replace characters
|
|
This function replaces all occurrences of the character @var{old-char}
|
|
with the character @var{new-char} in the region of the current buffer
|
|
defined by @var{start} and @var{end}. Both characters must have the
|
|
same length of their multibyte form.
|
|
|
|
@cindex undo avoidance
|
|
If @var{noundo} is non-@code{nil}, then @code{subst-char-in-region} does
|
|
not record the change for undo and does not mark the buffer as modified.
|
|
This was useful for controlling the old selective display feature
|
|
(@pxref{Selective Display}).
|
|
|
|
@code{subst-char-in-region} does not move point and returns
|
|
@code{nil}.
|
|
|
|
@example
|
|
@group
|
|
---------- Buffer: foo ----------
|
|
This is the contents of the buffer before.
|
|
---------- Buffer: foo ----------
|
|
@end group
|
|
|
|
@group
|
|
(subst-char-in-region 1 20 ?i ?X)
|
|
@result{} nil
|
|
|
|
---------- Buffer: foo ----------
|
|
ThXs Xs the contents of the buffer before.
|
|
---------- Buffer: foo ----------
|
|
@end group
|
|
@end example
|
|
@end defun
|
|
|
|
|
|
@defun subst-char-in-string fromchar tochar string &optional inplace
|
|
@cindex replace characters in string
|
|
This function replaces all occurrences of the character @var{fromchar}
|
|
with @var{tochar} in @var{string}. By default, substitution occurs in
|
|
a copy of @var{string}, but if the optional argument @var{inplace} is
|
|
non-@code{nil}, the function modifies the @var{string} itself. In any
|
|
case, the function returns the resulting string.
|
|
@end defun
|
|
|
|
@deffn Command translate-region start end table
|
|
This function applies a translation table to the characters in the
|
|
buffer between positions @var{start} and @var{end}.
|
|
|
|
The translation table @var{table} is a string or a char-table;
|
|
@code{(aref @var{table} @var{ochar})} gives the translated character
|
|
corresponding to @var{ochar}. If @var{table} is a string, any
|
|
characters with codes larger than the length of @var{table} are not
|
|
altered by the translation.
|
|
|
|
The return value of @code{translate-region} is the number of
|
|
characters that were actually changed by the translation. This does
|
|
not count characters that were mapped into themselves in the
|
|
translation table.
|
|
@end deffn
|
|
|
|
@node Registers
|
|
@section Registers
|
|
@cindex registers
|
|
|
|
A register is a sort of variable used in Emacs editing that can hold a
|
|
variety of different kinds of values. Each register is named by a
|
|
single character. All @acronym{ASCII} characters and their meta variants
|
|
(but with the exception of @kbd{C-g}) can be used to name registers.
|
|
Thus, there are 255 possible registers. A register is designated in
|
|
Emacs Lisp by the character that is its name.
|
|
|
|
@defvar register-alist
|
|
This variable is an alist of elements of the form @code{(@var{name} .
|
|
@var{contents})}. Normally, there is one element for each Emacs
|
|
register that has been used.
|
|
|
|
The object @var{name} is a character (an integer) identifying the
|
|
register.
|
|
@end defvar
|
|
|
|
The @var{contents} of a register can have several possible types:
|
|
|
|
@table @asis
|
|
@item a number
|
|
A number stands for itself. If @code{insert-register} finds a number
|
|
in the register, it converts the number to decimal.
|
|
|
|
@item a marker
|
|
A marker represents a buffer position to jump to.
|
|
|
|
@item a string
|
|
A string is text saved in the register.
|
|
|
|
@item a rectangle
|
|
@cindex rectangle, as contents of a register
|
|
A rectangle is represented by a list of strings.
|
|
|
|
@item @code{(@var{window-configuration} @var{position})}
|
|
This represents a window configuration to restore in one frame, and a
|
|
position to jump to in the current buffer.
|
|
|
|
@cindex frameset
|
|
@item @code{(@var{frame-configuration} @var{position})}
|
|
This represents a frame configuration to restore, and a position
|
|
to jump to in the current buffer. Frame configurations are also
|
|
known as @dfn{framesets}.
|
|
|
|
@item @code{(file @var{filename})}
|
|
This represents a file to visit; jumping to this value visits file
|
|
@var{filename}.
|
|
|
|
@item @code{(file-query @var{filename} @var{position})}
|
|
This represents a file to visit and a position in it; jumping to this
|
|
value visits file @var{filename} and goes to buffer position
|
|
@var{position}. Restoring this type of position asks the user for
|
|
confirmation first.
|
|
|
|
@item @code{(buffer @var{buffer-name})}
|
|
This represents a buffer; jumping to this value switches to buffer
|
|
@var{buffer-name}.
|
|
@end table
|
|
|
|
The functions in this section return unpredictable values unless
|
|
otherwise stated.
|
|
|
|
@defun get-register reg
|
|
This function returns the contents of the register
|
|
@var{reg}, or @code{nil} if it has no contents.
|
|
@end defun
|
|
|
|
@defun set-register reg value
|
|
This function sets the contents of register @var{reg} to @var{value}.
|
|
A register can be set to any value, but the other register functions
|
|
expect only certain data types. The return value is @var{value}.
|
|
@end defun
|
|
|
|
@deffn Command view-register reg
|
|
This command displays what is contained in register @var{reg}.
|
|
@end deffn
|
|
|
|
@deffn Command insert-register reg &optional beforep
|
|
This command inserts contents of register @var{reg} into the current
|
|
buffer.
|
|
|
|
Normally, this command puts point before the inserted text, and the
|
|
mark after it. However, if the optional second argument @var{beforep}
|
|
is non-@code{nil}, it puts the mark before and point after.
|
|
|
|
When called interactively, the command defaults to putting point after
|
|
text, and a prefix argument inverts this behavior.
|
|
|
|
If the register contains a rectangle, then the rectangle is inserted
|
|
with its upper left corner at point. This means that text is inserted
|
|
in the current line and underneath it on successive lines.
|
|
|
|
If the register contains something other than saved text (a string) or
|
|
a rectangle (a list), currently useless things happen. This may be
|
|
changed in the future.
|
|
@end deffn
|
|
|
|
@defun register-read-with-preview prompt
|
|
@cindex register preview
|
|
This function reads and returns a register name, prompting with
|
|
@var{prompt} and possibly showing a preview of the existing registers
|
|
and their contents. The preview is shown in a temporary window, after
|
|
the delay specified by the user option @code{register-preview-delay},
|
|
if its value and @code{register-alist} are both non-@code{nil}. The
|
|
preview is also shown if the user requests help (e.g., by typing the
|
|
help character). We recommend that all interactive commands which
|
|
read register names use this function.
|
|
@end defun
|
|
|
|
@node Transposition
|
|
@section Transposition of Text
|
|
|
|
This function can be used to transpose stretches of text:
|
|
|
|
@defun transpose-regions start1 end1 start2 end2 &optional leave-markers
|
|
This function exchanges two nonoverlapping portions of the buffer (if
|
|
they overlap, the function signals an error). Arguments @var{start1}
|
|
and @var{end1} specify the bounds of one portion and arguments
|
|
@var{start2} and @var{end2} specify the bounds of the other portion.
|
|
|
|
Normally, @code{transpose-regions} relocates markers with the transposed
|
|
text; a marker previously positioned within one of the two transposed
|
|
portions moves along with that portion, thus remaining between the same
|
|
two characters in their new position. However, if @var{leave-markers}
|
|
is non-@code{nil}, @code{transpose-regions} does not do this---it leaves
|
|
all markers unrelocated.
|
|
@end defun
|
|
|
|
@node Replacing
|
|
@section Replacing Buffer Text
|
|
|
|
You can use the following function to replace the text of one buffer
|
|
with the text of another buffer:
|
|
|
|
@deffn Command replace-buffer-contents source &optional max-secs max-costs
|
|
This function replaces the accessible portion of the current buffer
|
|
with the accessible portion of the buffer @var{source}. @var{source}
|
|
may either be a buffer object or the name of a buffer. When
|
|
@code{replace-buffer-contents} succeeds, the text of the accessible
|
|
portion of the current buffer will be equal to the text of the
|
|
accessible portion of the @var{source} buffer.
|
|
|
|
This function attempts to keep point, markers, text properties, and
|
|
overlays in the current buffer intact. One potential case where this
|
|
behavior is useful is external code formatting programs: they
|
|
typically write the reformatted text into a temporary buffer or file,
|
|
and using @code{delete-region} and @code{insert-buffer-substring}
|
|
would destroy these properties. However, the latter combination is
|
|
typically faster (@xref{Deletion}, and @ref{Insertion}).
|
|
|
|
For its working, @code{replace-buffer-contents} needs to compare the
|
|
contents of the original buffer with that of @var{source} which is a
|
|
costly operation if the buffers are huge and there is a high number of
|
|
differences between them. In order to keep
|
|
@code{replace-buffer-contents}'s runtime in bounds, it has two
|
|
optional arguments.
|
|
|
|
@var{max-secs} defines a hard boundary in terms of seconds. If given
|
|
and exceeded, it will fall back to @code{delete-region} and
|
|
@code{insert-buffer-substring}.
|
|
|
|
@var{max-costs} defines the quality of the difference computation. If
|
|
the actual costs exceed this limit, heuristics are used to provide a
|
|
faster but suboptimal solution. The default value is 1000000.
|
|
|
|
@code{replace-buffer-contents} returns @code{t} if a non-destructive
|
|
replacement could be performed. Otherwise, i.e., if @var{max-secs}
|
|
was exceeded, it returns @code{nil}.
|
|
@end deffn
|
|
|
|
@defun replace-region-contents beg end replace-fn &optional max-secs max-costs
|
|
This function replaces the region between @var{beg} and @var{end}
|
|
using the given @var{replace-fn}. The function @var{replace-fn} is
|
|
run in the current buffer narrowed to the specified region and it
|
|
should return either a string or a buffer replacing the region.
|
|
|
|
The replacement is performed using @code{replace-buffer-contents} (see
|
|
above) which also describes the @var{max-secs} and @var{max-costs}
|
|
arguments and the return value.
|
|
|
|
Note: If the replacement is a string, it will be placed in a temporary
|
|
buffer so that @code{replace-buffer-contents} can operate on it.
|
|
Therefore, if you already have the replacement in a buffer, it makes
|
|
no sense to convert it to a string using @code{buffer-substring} or
|
|
similar.
|
|
@end defun
|
|
|
|
@node Decompression
|
|
@section Dealing With Compressed Data
|
|
|
|
When @code{auto-compression-mode} is enabled, Emacs automatically
|
|
uncompresses compressed files when you visit them, and automatically
|
|
recompresses them if you alter and save them. @xref{Compressed
|
|
Files,,, emacs, The GNU Emacs Manual}.
|
|
|
|
The above feature works by calling an external executable (e.g.,
|
|
@command{gzip}). Emacs can also be compiled with support for built-in
|
|
decompression using the zlib library, which is faster than calling an
|
|
external program.
|
|
|
|
@defun zlib-available-p
|
|
This function returns non-@code{nil} if built-in zlib decompression is
|
|
available.
|
|
@end defun
|
|
|
|
@defun zlib-decompress-region start end &optional allow-partial
|
|
This function decompresses the region between @var{start} and
|
|
@var{end}, using built-in zlib decompression. The region should
|
|
contain data that were compressed with gzip or zlib. On success, the
|
|
function replaces the contents of the region with the decompressed
|
|
data. If @var{allow-partial} is @code{nil} or omitted, then on
|
|
failure, the function leaves the region unchanged and returns
|
|
@code{nil}. Otherwise, it returns the number of bytes that were not
|
|
decompressed and replaces the region text by whatever data was
|
|
successfully decompressed. This function can be called only in
|
|
unibyte buffers.
|
|
@end defun
|
|
|
|
|
|
@node Base 64
|
|
@section Base 64 Encoding
|
|
@cindex base 64 encoding
|
|
|
|
Base 64 code is used in email to encode a sequence of 8-bit bytes as
|
|
a longer sequence of @acronym{ASCII} graphic characters. It is defined in
|
|
Internet RFC@footnote{
|
|
An RFC, an acronym for @dfn{Request for Comments}, is a numbered
|
|
Internet informational document describing a standard. RFCs are
|
|
usually written by technical experts acting on their own initiative,
|
|
and are traditionally written in a pragmatic, experience-driven
|
|
manner.
|
|
}2045 and also in RFC 4648. This section describes the functions for
|
|
converting to and from this code.
|
|
|
|
@deffn Command base64-encode-region beg end &optional no-line-break
|
|
This function converts the region from @var{beg} to @var{end} into base
|
|
64 code. It returns the length of the encoded text. An error is
|
|
signaled if a character in the region is multibyte, i.e., in a
|
|
multibyte buffer the region must contain only ASCII characters or raw
|
|
bytes.
|
|
|
|
Normally, this function inserts newline characters into the encoded
|
|
text, to avoid overlong lines. However, if the optional argument
|
|
@var{no-line-break} is non-@code{nil}, these newlines are not added, so
|
|
the output is just one long line.
|
|
@end deffn
|
|
|
|
@deffn Command base64url-encode-region beg end &optional no-pad
|
|
This function is like @code{base64-encode-region}, but it implements
|
|
the URL variant of base 64 encoding, per RFC 4648, and it doesn't
|
|
insert newline characters into the encoded text, so the output is
|
|
just one long line.
|
|
|
|
If the optional argument @var{no-pad} is non-@code{nil} then this
|
|
function doesn't generate the padding (@code{=}).
|
|
@end deffn
|
|
|
|
@defun base64-encode-string string &optional no-line-break
|
|
This function converts the string @var{string} into base 64 code. It
|
|
returns a string containing the encoded text. As for
|
|
@code{base64-encode-region}, an error is signaled if a character in the
|
|
string is multibyte.
|
|
|
|
Normally, this function inserts newline characters into the encoded
|
|
text, to avoid overlong lines. However, if the optional argument
|
|
@var{no-line-break} is non-@code{nil}, these newlines are not added, so
|
|
the result string is just one long line.
|
|
@end defun
|
|
|
|
@defun base64url-encode-string string &optional no-pad
|
|
Like @code{base64-encode-string}, but generates the URL variant of
|
|
base 64, and doesn't insert newline characters into the encoded text,
|
|
so the result is just one long line.
|
|
|
|
If the optional argument @var{no-pad} is non-@code{nil} then this
|
|
function doesn't generate the padding.
|
|
@end defun
|
|
|
|
@deffn Command base64-decode-region beg end &optional base64url ignore-invalid
|
|
This function converts the region from @var{beg} to @var{end} from base
|
|
64 code into the corresponding decoded text. It returns the length of
|
|
the decoded text.
|
|
|
|
The decoding functions ignore newline characters in the encoded text.
|
|
|
|
If optional argument @var{base64url} is non-@code{nil}, then padding
|
|
is optional, and the URL variant of base 64 encoding is used.
|
|
If optional argument @var{ignore-invalid} is non-@code{nil}, then any
|
|
unrecognized characters are ignored.
|
|
@end deffn
|
|
|
|
@defun base64-decode-string string &optional base64url ignore-invalid
|
|
This function converts the string @var{string} from base 64 code into
|
|
the corresponding decoded text. It returns a unibyte string containing the
|
|
decoded text.
|
|
|
|
The decoding functions ignore newline characters in the encoded text.
|
|
|
|
|
|
If optional argument @var{base64url} is non-@code{nil}, then padding
|
|
is optional, and the URL variant of base 64 encoding is used.
|
|
If optional argument @var{ignore-invalid} is non-@code{nil}, then any
|
|
unrecognized characters are ignored.
|
|
@end defun
|
|
|
|
@node Checksum/Hash
|
|
@section Checksum/Hash
|
|
@cindex MD5 checksum
|
|
@cindex SHA hash
|
|
@cindex hash, cryptographic
|
|
@cindex cryptographic hash
|
|
|
|
Emacs has built-in support for computing @dfn{cryptographic hashes}.
|
|
A cryptographic hash, or @dfn{checksum}, is a digital fingerprint
|
|
of a piece of data (e.g., a block of text) which can be used to check
|
|
that you have an unaltered copy of that data.
|
|
|
|
@cindex message digest
|
|
Emacs supports several common cryptographic hash algorithms: MD5,
|
|
SHA-1, SHA-2, SHA-224, SHA-256, SHA-384 and SHA-512. MD5 is the
|
|
oldest of these algorithms, and is commonly used in @dfn{message
|
|
digests} to check the integrity of messages transmitted over a
|
|
network. MD5 and SHA-1 are not collision resistant (i.e., it is
|
|
possible to deliberately design different pieces of data which have
|
|
the same MD5 or SHA-1 hash), so you should not use them for anything
|
|
security-related. For security-related applications you should use
|
|
the other hash types, such as SHA-2 (e.g. @code{sha256} or
|
|
@code{sha512}).
|
|
|
|
@defun secure-hash-algorithms
|
|
This function returns a list of symbols representing algorithms that
|
|
@code{secure-hash} can use.
|
|
@end defun
|
|
|
|
@defun secure-hash algorithm object &optional start end binary
|
|
This function returns a hash for @var{object}. The argument
|
|
@var{algorithm} is a symbol stating which hash to compute: one of
|
|
@code{md5}, @code{sha1}, @code{sha224}, @code{sha256}, @code{sha384}
|
|
or @code{sha512}. The argument @var{object} should be a buffer or a
|
|
string.
|
|
|
|
The optional arguments @var{start} and @var{end} are character
|
|
positions specifying the portion of @var{object} to compute the
|
|
message digest for. If they are @code{nil} or omitted, the hash is
|
|
computed for the whole of @var{object}.
|
|
|
|
If the argument @var{binary} is omitted or @code{nil}, the function
|
|
returns the @dfn{text form} of the hash, as an ordinary Lisp string.
|
|
If @var{binary} is non-@code{nil}, it returns the hash in @dfn{binary
|
|
form}, as a sequence of bytes stored in a unibyte string. The length
|
|
of the returned string depends on @var{algorithm}:
|
|
|
|
@itemize
|
|
@item
|
|
For @code{md5}: 32 characters (16 bytes if @var{binary} is
|
|
non-@code{nil}).
|
|
@item
|
|
For @code{sha1}: 40 characters (20 bytes if @var{binary} is
|
|
non-@code{nil}).
|
|
@item
|
|
For @code{sha224}: 56 characters (28 bytes if @var{binary} is
|
|
non-@code{nil}).
|
|
@item
|
|
For @code{sha256}: 64 characters (32 bytes if @var{binary} is
|
|
non-@code{nil}).
|
|
@item
|
|
For @code{sha384}: 96 characters (48 bytes if @var{binary} is
|
|
non-@code{nil}).
|
|
@item
|
|
For @code{sha512}: 128 characters (64 bytes if @var{binary} is
|
|
non-@code{nil}).
|
|
@end itemize
|
|
|
|
This function does not compute the hash directly from the internal
|
|
representation of @var{object}'s text (@pxref{Text Representations}).
|
|
Instead, it encodes the text using a coding system (@pxref{Coding
|
|
Systems}), and computes the hash from that encoded text. If
|
|
@var{object} is a buffer, the coding system used is the one which
|
|
would be chosen by default for writing the text of that buffer into a
|
|
file. If @var{object} is a string, the user's preferred coding system
|
|
is used (@pxref{Recognize Coding,,, emacs, GNU Emacs Manual}).
|
|
@end defun
|
|
|
|
@defun md5 object &optional start end coding-system noerror
|
|
This function returns an MD5 hash. It is semi-obsolete, since for
|
|
most purposes it is equivalent to calling @code{secure-hash} with
|
|
@code{md5} as the @var{algorithm} argument. The @var{object},
|
|
@var{start} and @var{end} arguments have the same meanings as in
|
|
@code{secure-hash}. The function returns a 32-character string.
|
|
|
|
If @var{coding-system} is non-@code{nil}, it specifies a coding system
|
|
to use to encode the text; if omitted or @code{nil}, the default
|
|
coding system is used, like in @code{secure-hash}.
|
|
|
|
Normally, @code{md5} signals an error if the text can't be encoded
|
|
using the specified or chosen coding system. However, if
|
|
@var{noerror} is non-@code{nil}, it silently uses @code{raw-text}
|
|
coding instead.
|
|
@end defun
|
|
|
|
@defun buffer-hash &optional buffer-or-name
|
|
Return a hash of @var{buffer-or-name}. If @code{nil}, this defaults
|
|
to the current buffer. As opposed to @code{secure-hash}, this
|
|
function computes the hash based on the internal representation of the
|
|
buffer, disregarding any coding systems. It's therefore only useful
|
|
when comparing two buffers running in the same Emacs, and is not
|
|
guaranteed to return the same hash between different Emacs versions.
|
|
It should be somewhat more efficient on larger buffers than
|
|
@code{secure-hash} is, and should not allocate more memory.
|
|
@c Note that we do not document what hashing function we're using, or
|
|
@c even whether it's a cryptographic hash, since that may change
|
|
@c according to what we find useful. We also don't document the
|
|
@c length of the hash string it returns, since that can be used to
|
|
@c guess the hashing function being used.
|
|
@end defun
|
|
|
|
@defun sha1 object &optional start end binary
|
|
This function is equivalent to calling @code{secure-hash} like this:
|
|
|
|
@lisp
|
|
(secure-hash 'sha1 object start end binary)
|
|
@end lisp
|
|
|
|
It returns a 40-character string if @var{binary} is @code{nil}, or a
|
|
20-byte unibyte string otherwise.
|
|
@end defun
|
|
|
|
@node Suspicious Text
|
|
@section Suspicious Text
|
|
@cindex suspicious text
|
|
@cindex insecure text
|
|
@cindex security vulnerabilities in text
|
|
|
|
Emacs can display text from many external sources, like email and Web
|
|
sites. Attackers may attempt to confuse the user reading this text by
|
|
using obfuscated @acronym{URL}s or email addresses, and tricking the
|
|
user into visiting a web page they didn't intend to visit, or sending
|
|
an email to the wrong address.
|
|
|
|
This usually involves using characters from scripts that visually look
|
|
like @acronym{ASCII} characters (i.e., are homoglyphs), but there are
|
|
also other techniques used, like using bidirectional overrides, or
|
|
having an @acronym{HTML} link text that says one thing, while the
|
|
underlying @acronym{URL} points somewhere else.
|
|
|
|
@cindex suspicious text strings
|
|
To help identify these @dfn{suspicious text strings}, Emacs provides a
|
|
library to do a number of checks on text. (See
|
|
@url{https://www.unicode.org/reports/tr39/, UTS #39: Unicode Security
|
|
Mechanisms} for the rationale behind the checks that are available and
|
|
more details about them.) Packages that present data that might be
|
|
suspicious should use this library to flag suspicious text on display.
|
|
|
|
@vindex textsec-check
|
|
@defun textsec-suspicious-p object type
|
|
This function is the high-level interface function that packages
|
|
should use. It respects the @code{textsec-check} user option, which
|
|
allows the user to disable the checks.
|
|
|
|
This function checks @var{object} (whose data type depends on
|
|
@var{type}) to see if it looks suspicious when interpreted as a thing
|
|
of @var{type}. The available types and the corresponding @var{object}
|
|
data types are:
|
|
|
|
@table @code
|
|
@item domain
|
|
Check whether a domain (e.g., @samp{www.gnu.org} looks suspicious.
|
|
@var{object} should be a string, the domain name.
|
|
|
|
@item url
|
|
Check whether an @acronym{URL} (e.g., @samp{http://gnu.org/foo/bar})
|
|
looks suspicious. @var{object} should be a string, the @acronym{URL}
|
|
to check.
|
|
|
|
@item link
|
|
Check whether an @acronym{HTML} link (e.g., @samp{<a
|
|
href='http://gnu.org'>fsf.org</a>} looks suspicious. In this case,
|
|
@var{object} should be a @code{cons} cell where the @code{car} is the
|
|
@acronym{URL} string, and the @code{cdr} is the link text. The link
|
|
is deemed suspicious if the link text contains a domain name, and that
|
|
domain name points to something other than the @acronym{URL}.
|
|
|
|
@item email-address
|
|
Check whether an email address (e.g., @samp{foo@@example.org}) looks
|
|
suspicious. @var{object} should be a string.
|
|
|
|
@item local-address
|
|
Check whether the local part of an email address (the bit before the
|
|
@samp{@@} sign) looks suspicious. @var{object} should be a string.
|
|
|
|
@item name
|
|
Check whether a name (used in an email address header) looks
|
|
suspicious. @var{object} should be a string.
|
|
|
|
@item email-address-header
|
|
Check whether a full RFC2822 email address header (e.g.,
|
|
@samp{=?utf-8?Q?=C3=81?= <foo@@example.com>}) looks suspicious.
|
|
@var{object} should be a string.
|
|
@end table
|
|
|
|
If @var{object} is suspicious, this function returns a string that
|
|
explains why it is suspicious. If @var{object} is not suspicious, the
|
|
function returns @code{nil}.
|
|
@end defun
|
|
|
|
@vindex textsec-suspicious@r{ (face)}
|
|
If the text is suspicious, the application should mark the suspicious
|
|
text with the @code{textsec-suspicious} face, and make the explanation
|
|
returned by @code{textsec-suspicious-p} available to the user in some way
|
|
(for example, in a tooltip). The application might also prompt the
|
|
user for confirmation before taking any action on a suspicious string
|
|
(like sending an email to a suspicious email address).
|
|
|
|
@node GnuTLS Cryptography
|
|
@section GnuTLS Cryptography
|
|
@cindex MD5 checksum
|
|
@cindex SHA hash
|
|
@cindex hash, cryptographic
|
|
@cindex cryptographic hash
|
|
@cindex AEAD cipher
|
|
@cindex cipher, AEAD
|
|
@cindex symmetric cipher
|
|
@cindex cipher, symmetric
|
|
|
|
If compiled with GnuTLS, Emacs offers built-in cryptographic
|
|
support. Following the GnuTLS API terminology, the available tools
|
|
are digests, MACs, symmetric ciphers, and AEAD ciphers.
|
|
|
|
The terms used herein, such as IV (Initialization Vector), require
|
|
some familiarity with cryptography and will not be defined in detail.
|
|
Please consult @uref{https://www.gnutls.org/} for specific
|
|
documentation which may help you understand the terminology and
|
|
structure of the GnuTLS library.
|
|
|
|
@menu
|
|
* Format of GnuTLS Cryptography Inputs::
|
|
* GnuTLS Cryptographic Functions::
|
|
@end menu
|
|
|
|
@node Format of GnuTLS Cryptography Inputs
|
|
@subsection Format of GnuTLS Cryptography Inputs
|
|
@cindex format of gnutls cryptography inputs
|
|
@cindex gnutls cryptography inputs format
|
|
|
|
The inputs to GnuTLS cryptographic functions can be specified in
|
|
several ways, both as primitive Emacs Lisp types or as lists.
|
|
|
|
The list form is currently similar to how @code{md5} and
|
|
@code{secure-hash} operate.
|
|
|
|
@table @code
|
|
@item @var{buffer}
|
|
Simply passing a buffer as input means the whole buffer should be used.
|
|
|
|
@item @var{string}
|
|
A string as input will be used directly. It may be modified by the
|
|
function (unlike most other Emacs Lisp functions) to reduce the chance
|
|
of exposing sensitive data after the function does its work.
|
|
|
|
@item (@var{buffer-or-string} @var{start} @var{end} @var{coding-system} @var{noerror})
|
|
This specifies a buffer or a string as described above, but an
|
|
optional range can be specified with @var{start} and @var{end}.
|
|
|
|
In addition an optional @var{coding-system} can be specified if needed.
|
|
|
|
The last optional item, @var{noerror}, overrides the normal error when
|
|
the text can't be encoded using the specified or chosen coding system.
|
|
When @var{noerror} is non-@code{nil}, this function silently uses
|
|
@code{raw-text} coding instead.
|
|
|
|
@item (@code{iv-auto} @var{length})
|
|
This generates a random IV (Initialization Vector) of the specified
|
|
length and passes it to the function. This ensures that the IV is
|
|
unpredictable and unlikely to be reused in the same session.
|
|
|
|
@end table
|
|
|
|
@node GnuTLS Cryptographic Functions
|
|
@subsection GnuTLS Cryptographic Functions
|
|
@cindex gnutls cryptographic functions
|
|
|
|
@defun gnutls-digests
|
|
This function returns the alist of the GnuTLS digest algorithms.
|
|
|
|
Each entry has a key which represents the algorithm, followed by a
|
|
plist with internal details about the algorithm. The plist will have
|
|
@code{:type gnutls-digest-algorithm} and also will have the key
|
|
@code{:digest-algorithm-length 64} to indicate the size, in bytes, of
|
|
the resulting digest.
|
|
|
|
There is a name parallel between GnuTLS MAC and digest algorithms but
|
|
they are separate things internally and should not be mixed.
|
|
@end defun
|
|
|
|
@defun gnutls-hash-digest digest-method input
|
|
The @var{digest-method} can be the whole plist from
|
|
@code{gnutls-digests}, or just the symbol key, or a string with the
|
|
name of that symbol.
|
|
|
|
The @var{input} can be specified as a buffer or string or in other
|
|
ways (@pxref{Format of GnuTLS Cryptography Inputs}).
|
|
|
|
This function returns @code{nil} on error, and signals a Lisp error if
|
|
the @var{digest-method} or @var{input} are invalid. On success, it
|
|
returns a list of a binary string (the output) and the IV used.
|
|
@end defun
|
|
|
|
@defun gnutls-macs
|
|
This function returns the alist of the GnuTLS MAC algorithms.
|
|
|
|
Each entry has a key which represents the algorithm, followed by a
|
|
plist with internal details about the algorithm. The plist will have
|
|
@code{:type gnutls-mac-algorithm} and also will have the keys
|
|
@code{:mac-algorithm-length} @code{:mac-algorithm-keysize}
|
|
@code{:mac-algorithm-noncesize} to indicate the size, in bytes, of the
|
|
resulting hash, the key, and the nonce respectively.
|
|
|
|
The nonce is currently unused and only some MACs support it.
|
|
|
|
There is a name parallel between GnuTLS MAC and digest algorithms but
|
|
they are separate things internally and should not be mixed.
|
|
@end defun
|
|
|
|
@defun gnutls-hash-mac hash-method key input
|
|
The @var{hash-method} can be the whole plist from
|
|
@code{gnutls-macs}, or just the symbol key, or a string with the
|
|
name of that symbol.
|
|
|
|
The @var{key} can be specified as a buffer or string or in other ways
|
|
(@pxref{Format of GnuTLS Cryptography Inputs}). The @var{key} will be
|
|
wiped after use if it's a string.
|
|
|
|
The @var{input} can be specified as a buffer or string or in other
|
|
ways (@pxref{Format of GnuTLS Cryptography Inputs}).
|
|
|
|
This function returns @code{nil} on error, and signals a Lisp error if
|
|
the @var{hash-method} or @var{key} or @var{input} are invalid.
|
|
|
|
On success, it returns a list of a binary string (the output) and the
|
|
IV used.
|
|
@end defun
|
|
|
|
@defun gnutls-ciphers
|
|
This function returns the alist of the GnuTLS ciphers.
|
|
|
|
Each entry has a key which represents the cipher, followed by a plist
|
|
with internal details about the algorithm. The plist will have
|
|
@code{:type gnutls-symmetric-cipher} and also will have the keys
|
|
@code{:cipher-aead-capable} set to @code{nil} or @code{t} to indicate
|
|
AEAD capability; and @code{:cipher-tagsize} @code{:cipher-blocksize}
|
|
@code{:cipher-keysize} @code{:cipher-ivsize} to indicate the size, in
|
|
bytes, of the tag, block size of the resulting data, the key, and the
|
|
IV respectively.
|
|
@end defun
|
|
|
|
@defun gnutls-symmetric-encrypt cipher key iv input &optional aead_auth
|
|
The @var{cipher} can be the whole plist from
|
|
@code{gnutls-ciphers}, or just the symbol key, or a string with the
|
|
name of that symbol.
|
|
|
|
The @var{key} can be specified as a buffer or string or in other ways
|
|
(@pxref{Format of GnuTLS Cryptography Inputs}). The @var{key} will be
|
|
wiped after use if it's a string.
|
|
|
|
The @var{iv} and @var{input} and the optional @var{aead_auth} can be
|
|
specified as a buffer or string or in other ways (@pxref{Format of
|
|
GnuTLS Cryptography Inputs}).
|
|
|
|
@var{aead_auth} is only checked with AEAD ciphers, that is, ciphers whose
|
|
plist has @code{:cipher-aead-capable t}. Otherwise it's ignored.
|
|
|
|
This function returns @code{nil} on error, and signals a Lisp error if
|
|
the @var{cipher} or @var{key}, @var{iv}, or @var{input} are invalid,
|
|
or if @var{aead_auth} was specified with an AEAD cipher and was
|
|
invalid.
|
|
|
|
On success, it returns a list of a binary string (the output) and the
|
|
IV used.
|
|
@end defun
|
|
|
|
@defun gnutls-symmetric-decrypt cipher key iv input &optional aead_auth
|
|
The @var{cipher} can be the whole plist from
|
|
@code{gnutls-ciphers}, or just the symbol key, or a string with the
|
|
name of that symbol.
|
|
|
|
The @var{key} can be specified as a buffer or string or in other ways
|
|
(@pxref{Format of GnuTLS Cryptography Inputs}). The @var{key} will be
|
|
wiped after use if it's a string.
|
|
|
|
The @var{iv} and @var{input} and the optional @var{aead_auth} can be
|
|
specified as a buffer or string or in other ways (@pxref{Format of
|
|
GnuTLS Cryptography Inputs}).
|
|
|
|
@var{aead_auth} is only checked with AEAD ciphers, that is, ciphers whose
|
|
plist has @code{:cipher-aead-capable t}. Otherwise it's ignored.
|
|
|
|
This function returns @code{nil} on decryption error, and signals a
|
|
Lisp error if the @var{cipher} or @var{key}, @var{iv}, or @var{input}
|
|
are invalid, or if @var{aead_auth} was specified with an AEAD cipher
|
|
and was invalid.
|
|
|
|
On success, it returns a list of a binary string (the output) and the
|
|
IV used.
|
|
@end defun
|
|
|
|
@node Database
|
|
@section Database
|
|
@cindex database access, SQLite
|
|
|
|
Emacs can be compiled with built-in support for accessing SQLite
|
|
databases. This section describes the facilities available for
|
|
accessing SQLite databases from Lisp programs.
|
|
|
|
@defun sqlite-available-p
|
|
The function returns non-@code{nil} if built-in SQLite support is
|
|
available in this Emacs session.
|
|
@end defun
|
|
|
|
When SQLite support is available, the following functions can be used.
|
|
|
|
@cindex database object
|
|
@defun sqlite-open &optional file
|
|
This function opens @var{file} as an SQLite database file. If
|
|
@var{file} doesn't exist, a new database will be created and stored in
|
|
that file. If @var{file} is omitted or @code{nil}, a new in-memory
|
|
database is created instead.
|
|
|
|
The return value is a @dfn{database object} that can be used as the
|
|
argument to most of the subsequent functions described below.
|
|
@end defun
|
|
|
|
@defun sqlitep object
|
|
This predicate returns non-@code{nil} if @var{object} is an SQLite
|
|
database object. The database object returned by the
|
|
@code{sqlite-open} function satisfies this predicate.
|
|
@end defun
|
|
|
|
@defun sqlite-close db
|
|
Close the database @var{db}. It's usually not necessary to call this
|
|
function explicitly---the database will automatically be closed if
|
|
Emacs shuts down or the database object is garbage collected.
|
|
@end defun
|
|
|
|
@defun sqlite-execute db statement &optional values
|
|
Execute the @acronym{SQL} @var{statement}. For instance:
|
|
|
|
@lisp
|
|
(sqlite-execute db "insert into foo values ('bar', 2)")
|
|
@end lisp
|
|
|
|
If the optional @var{values} parameter is present, it should be either
|
|
a list or a vector of values to bind while executing the statement.
|
|
For instance:
|
|
|
|
@lisp
|
|
(sqlite-execute db "insert into foo values (?, ?)" '("bar" 2))
|
|
@end lisp
|
|
|
|
This has exactly the same effect as the previous example, but is more
|
|
efficient and safer (because it doesn't involve any string parsing or
|
|
interpolation).
|
|
|
|
@code{sqlite-execute} usually returns the number of affected rows.
|
|
For instance, an @samp{insert} statement will typically return
|
|
@samp{1}, whereas an @samp{update} statement may return zero or a
|
|
higher number. However, when using @acronym{SQL} statements like
|
|
@w{@samp{insert into @dots{} returning @dots{}}} and the like, the values
|
|
specified by @w{@samp{returning @dots{}}} will be returned instead.
|
|
|
|
Strings in SQLite are, by default, stored as @code{utf-8}, and
|
|
selecting a text column will decode the string using that charset.
|
|
Selecting a blob column will return the raw data without any decoding
|
|
(i.e., it will return a unibyte string containing the bytes as stored
|
|
in the database). Inserting binary data into blob columns, however,
|
|
requires some care, as @code{sqlite-execute} will, by default,
|
|
interpret all strings as @code{utf-8}.
|
|
|
|
So if you have, for instance, @acronym{GIF} data in a unibyte string
|
|
called @var{gif}, you have to mark it specially to let
|
|
@code{sqlite-execute} know this:
|
|
|
|
@lisp
|
|
(put-text-property 0 1 'coding-system 'binary gif)
|
|
(sqlite-execute db "insert into foo values (?, ?)" (list gif 2))
|
|
@end lisp
|
|
|
|
@end defun
|
|
|
|
@defun sqlite-execute-batch db statements
|
|
Execute the @acronym{SQL} @var{statements}. @var{statements} is a
|
|
string containing 0 or more @acronym{SQL} statements. This command
|
|
might be useful when a Lisp program needs to execute multiple Data
|
|
Definition Language (@acronym{DDL}) statements in one go.
|
|
|
|
@end defun
|
|
|
|
@defun sqlite-select db query &optional values return-type
|
|
Select some data from @var{db} and return them. For instance:
|
|
|
|
@lisp
|
|
(sqlite-select db "select * from foo where key = 2")
|
|
@result{} (("bar" 2))
|
|
@end lisp
|
|
|
|
As with the @code{sqlite-execute}, you can optionally pass in a list
|
|
or a vector of values that will be bound before executing the select:
|
|
|
|
@lisp
|
|
(sqlite-select db "select * from foo where key = ?" [2])
|
|
@result{} (("bar" 2))
|
|
@end lisp
|
|
|
|
This is usually more efficient and safer than the method used by the
|
|
previous example.
|
|
|
|
By default, this function returns a list of matching rows, where each
|
|
row is a list of column values. If @var{return-type} is @code{full},
|
|
the names of the columns (as a list of strings) will be returned as
|
|
the first element in the return value.
|
|
|
|
@cindex statement object
|
|
If @var{return-type} is @code{set}, this function will return a
|
|
@dfn{statement object} instead. This object can be examined by using
|
|
the @code{sqlite-next}, @code{sqlite-columns} and @code{sqlite-more-p}
|
|
functions. If the result set is small, it's often more convenient to
|
|
just return the data directly, but if the result set is large (or if
|
|
you won't be using all the data from the set), using the @code{set}
|
|
method will allocate a lot less memory, and is therefore more
|
|
memory-efficient.
|
|
@end defun
|
|
|
|
@defun sqlite-next statement
|
|
This function returns the next row in the result set @var{statement},
|
|
typically an object returned by @code{sqlite-select}.
|
|
|
|
@lisp
|
|
(sqlite-next stmt)
|
|
@result{} ("bar" 2)
|
|
@end lisp
|
|
@end defun
|
|
|
|
@defun sqlite-columns statement
|
|
This function returns the column names of the result set
|
|
@var{statement}, typically an object returned by @code{sqlite-select}.
|
|
|
|
@lisp
|
|
(sqlite-columns stmt)
|
|
@result{} ("name" "issue")
|
|
@end lisp
|
|
@end defun
|
|
|
|
@defun sqlite-more-p statement
|
|
This predicate says whether there is more data to be fetched from the
|
|
result set @var{statement}, typically an object returned by
|
|
@code{sqlite-select}.
|
|
@end defun
|
|
|
|
@defun sqlite-finalize statement
|
|
If @var{statement} is not going to be used any more, calling this
|
|
function will free the resources used by @var{statement}. This is
|
|
usually not necessary---when the @var{statement} object is
|
|
garbage-collected, Emacs will automatically free its resources.
|
|
@end defun
|
|
|
|
@defun sqlite-transaction db
|
|
Start a transaction in @var{db}. When in a transaction, other readers
|
|
of the database won't access the results until the transaction has
|
|
been committed by @code{sqlite-commit}.
|
|
@end defun
|
|
|
|
@defun sqlite-commit db
|
|
End a transaction in @var{db} and write the data out to its file.
|
|
@end defun
|
|
|
|
@defun sqlite-rollback db
|
|
End a transaction in @var{db} and discard any changes that have been
|
|
made by the transaction.
|
|
@end defun
|
|
|
|
@defmac with-sqlite-transaction db body@dots{}
|
|
Like @code{progn} (@pxref{Sequencing}), but executes @var{body} with a
|
|
transaction held, and commits the transaction at the end if @var{body}
|
|
completes normally. If @var{body} signals an error, or committing the
|
|
transaction fails, the changes in @var{db} performed by @var{body} are
|
|
rolled back. The macro returns the value of @var{body} if it
|
|
completes normally and commit succeeds.
|
|
@end defmac
|
|
|
|
@defun sqlite-pragma db pragma
|
|
Execute @var{pragma} in @var{db}. A @dfn{pragma} is usually a command
|
|
that affects the database overall, instead of any particular table.
|
|
For instance, to make SQLite automatically garbage collect data that's
|
|
no longer needed, you can say:
|
|
|
|
@lisp
|
|
(sqlite-pragma db "auto_vacuum = FULL")
|
|
@end lisp
|
|
|
|
This function returns non-@code{nil} on success and @code{nil} if the
|
|
pragma failed. Many pragmas can only be issued when the database is
|
|
brand new and empty.
|
|
@end defun
|
|
|
|
@defun sqlite-load-extension db module
|
|
Load the named extension @var{module} into the database @var{db}.
|
|
Extensions are usually shared-library files; on GNU and Unix systems,
|
|
they have the @file{.so} file-name extension.
|
|
@end defun
|
|
|
|
@defun sqlite-version
|
|
Return a string denoting the version of the SQLite library in use.
|
|
@end defun
|
|
|
|
@findex sqlite-mode-open-file
|
|
If you wish to list the contents of an SQLite file, you can use the
|
|
@code{sqlite-mode-open-file} command. This will pop to a buffer using
|
|
@code{sqlite-mode}, which allows you to examine (and alter) the
|
|
contents of an SQLite database.
|
|
|
|
@node Parsing HTML/XML
|
|
@section Parsing HTML and XML
|
|
@cindex parsing html
|
|
|
|
Emacs can be compiled with built-in @file{libxml2} support.
|
|
|
|
@defun libxml-available-p
|
|
This function returns non-@code{nil} if built-in libxml2 support is
|
|
available in this Emacs session.
|
|
@end defun
|
|
|
|
When libxml2 support is available, the following functions can be used
|
|
to parse HTML or XML text into Lisp object trees.
|
|
|
|
@defun libxml-parse-html-region &optional start end base-url discard-comments
|
|
This function parses the text between @var{start} and @var{end} as
|
|
HTML, and returns a list representing the HTML @dfn{parse tree}. It
|
|
attempts to handle real-world HTML by robustly coping with syntax
|
|
mistakes.
|
|
|
|
If @var{start} or @var{end} are @code{nil}, they default to the values
|
|
from @code{point-min} and @code{point-max}, respectively.
|
|
|
|
The optional argument @var{base-url}, if non-@code{nil}, should be
|
|
used for warnings and errors reported by the @file{libxml2} library,
|
|
but Emacs currently calls the library with errors and warnings
|
|
disabled, so this argument is not used.
|
|
|
|
If the optional argument @var{discard-comments} is non-@code{nil},
|
|
any top-level comment is discarded. (This argument is obsolete and
|
|
will be removed in future Emacs versions. To remove comments, use the
|
|
@code{xml-remove-comments} utility function on the data before you
|
|
call the parsing function.)
|
|
|
|
In the parse tree, each HTML node is represented by a list in which
|
|
the first element is a symbol representing the node name, the second
|
|
element is an alist of node attributes, and the remaining elements are
|
|
the subnodes.
|
|
|
|
The following example demonstrates this. Given this (malformed) HTML
|
|
document:
|
|
|
|
@example
|
|
<html><head></head><body width=101><div class=thing>Foo<div>Yes
|
|
@end example
|
|
|
|
@noindent
|
|
A call to @code{libxml-parse-html-region} returns this @acronym{DOM}
|
|
(document object model):
|
|
|
|
@example
|
|
(html nil
|
|
(head nil)
|
|
(body ((width . "101"))
|
|
(div ((class . "thing"))
|
|
"Foo"
|
|
(div nil
|
|
"Yes"))))
|
|
@end example
|
|
@end defun
|
|
|
|
@cindex rendering html
|
|
@defun shr-insert-document dom
|
|
This function renders the parsed HTML in @var{dom} into the current
|
|
buffer. The argument @var{dom} should be a list as generated by
|
|
@code{libxml-parse-html-region}. This function is, e.g., used by
|
|
@ref{Top, EWW,, eww, The Emacs Web Wowser Manual}.
|
|
@end defun
|
|
|
|
@cindex parsing xml
|
|
@defun libxml-parse-xml-region &optional start end base-url discard-comments
|
|
This function is the same as @code{libxml-parse-html-region}, except
|
|
that it parses the text as XML rather than HTML (so it is stricter
|
|
about syntax).
|
|
@end defun
|
|
|
|
@menu
|
|
* Document Object Model:: Access, manipulate and search the @acronym{DOM}.
|
|
@end menu
|
|
|
|
@node Document Object Model
|
|
@subsection Document Object Model
|
|
@cindex HTML DOM
|
|
@cindex XML DOM
|
|
@cindex DOM
|
|
@cindex Document Object Model
|
|
|
|
The @acronym{DOM} returned by @code{libxml-parse-html-region} (and
|
|
the other @acronym{XML} parsing functions) is a tree structure where
|
|
each node has a node name (called a @dfn{tag}), and optional key/value
|
|
@dfn{attribute} list, and then a list of @dfn{child nodes}. The child
|
|
nodes are either strings or @acronym{DOM} objects.
|
|
|
|
@example
|
|
(body ((width . "101"))
|
|
(div ((class . "thing"))
|
|
"Foo"
|
|
(div nil
|
|
"Yes")))
|
|
@end example
|
|
|
|
@defun dom-node tag &optional attributes &rest children
|
|
This function creates a @acronym{DOM} node of type @var{tag}. If
|
|
given, @var{attributes} should be a key/value pair list.
|
|
If given, @var{children} should be @acronym{DOM} nodes.
|
|
@end defun
|
|
|
|
The following functions can be used to work with this structure. Each
|
|
function takes a @acronym{DOM} node, or a list of nodes. In the
|
|
latter case, only the first node in the list is used.
|
|
|
|
Simple accessors:
|
|
|
|
@table @code
|
|
@item dom-tag @var{node}
|
|
Return the @dfn{tag} (also called ``node name'') of the node.
|
|
|
|
@item dom-attr @var{node} @var{attribute}
|
|
Return the value of @var{attribute} in the node. A common usage
|
|
would be:
|
|
|
|
@lisp
|
|
(dom-attr img 'href)
|
|
=> "https://fsf.org/logo.png"
|
|
@end lisp
|
|
|
|
@item dom-children @var{node}
|
|
Return all the children of the node.
|
|
|
|
@item dom-non-text-children @var{node}
|
|
Return all the non-string children of the node.
|
|
|
|
@item dom-attributes @var{node}
|
|
Return the key/value pair list of attributes of the node.
|
|
|
|
@item dom-text @var{node}
|
|
Return all the textual elements of the node as a concatenated string.
|
|
|
|
@item dom-texts @var{node}
|
|
Return all the textual elements of the node, as well as the textual
|
|
elements of all the children of the node, recursively, as a
|
|
concatenated string. This function also takes an optional separator
|
|
to be inserted between the textual elements.
|
|
|
|
@item dom-parent @var{dom} @var{node}
|
|
Return the parent of @var{node} in @var{dom}.
|
|
|
|
@item dom-remove @var{dom} @var{node}
|
|
Remove @var{node} from @var{dom}.
|
|
@end table
|
|
|
|
The following are functions for altering the @acronym{DOM}.
|
|
|
|
@table @code
|
|
@item dom-set-attribute @var{node} @var{attribute} @var{value}
|
|
Set the @var{attribute} of the node to @var{value}.
|
|
|
|
@item dom-remove-attribute @var{node} @var{attribute}
|
|
Remove @var{attribute} from @var{node}.
|
|
|
|
@item dom-append-child @var{node} @var{child}
|
|
Append @var{child} as the last child of @var{node}.
|
|
|
|
@item dom-add-child-before @var{node} @var{child} @var{before}
|
|
Add @var{child} to @var{node}'s child list before the @var{before}
|
|
node. If @var{before} is @code{nil}, make @var{child} the first child.
|
|
|
|
@item dom-set-attributes @var{node} @var{attributes}
|
|
Replace all the attributes of the node with a new key/value list.
|
|
@end table
|
|
|
|
The following are functions for searching for elements in the
|
|
@acronym{DOM}. They all return lists of matching nodes.
|
|
|
|
@table @code
|
|
@item dom-by-tag @var{dom} @var{tag}
|
|
Return all nodes in @var{dom} that are of type @var{tag}. A typical
|
|
use would be:
|
|
|
|
@lisp
|
|
(dom-by-tag dom 'td)
|
|
=> '((td ...) (td ...) (td ...))
|
|
@end lisp
|
|
|
|
@item dom-by-class @var{dom} @var{match}
|
|
Return all nodes in @var{dom} that have class names that match
|
|
@var{match}, which is a regular expression.
|
|
|
|
@item dom-by-style @var{dom} @var{style}
|
|
Return all nodes in @var{dom} that have styles that match @var{match},
|
|
which is a regular expression.
|
|
|
|
@item dom-by-id @var{dom} @var{style}
|
|
Return all nodes in @var{dom} that have IDs that match @var{match},
|
|
which is a regular expression.
|
|
|
|
@item dom-search @var{dom} @var{predicate}
|
|
Return all nodes in @var{dom} where @var{predicate} returns a
|
|
non-@code{nil} value. @var{predicate} is called with the node to be
|
|
tested as its parameter.
|
|
|
|
@item dom-strings @var{dom}
|
|
Return all strings in @var{dom}.
|
|
|
|
@end table
|
|
|
|
Utility functions:
|
|
|
|
@table @code
|
|
@item dom-pp @var{dom} &optional @var{remove-empty}
|
|
Pretty-print @var{dom} at point. If @var{remove-empty}, don't print
|
|
textual nodes that just contain white-space.
|
|
|
|
@item dom-print @var{dom} &optional @var{pretty} @var{xml}
|
|
Print @var{dom} at point. If @var{xml} is non-@code{nil}, print as
|
|
@acronym{XML}; otherwise, print as @acronym{HTML}. If @var{pretty} is
|
|
non-@code{nil}, indent the @acronym{HTML}/@acronym{XML} logically.
|
|
@end table
|
|
|
|
|
|
@node Parsing JSON
|
|
@section Parsing and generating JSON values
|
|
@cindex JSON
|
|
@cindex JavaScript Object Notation
|
|
|
|
The Emacs @acronym{JSON} (@dfn{JavaScript Object Notation}) support
|
|
provides several functions to convert between Lisp objects and JSON
|
|
values. Any JSON value can be converted to a Lisp object, but not vice
|
|
versa. Specifically:
|
|
|
|
@itemize
|
|
@item
|
|
JSON uses three keywords: @code{true}, @code{null}, @code{false}.
|
|
@code{true} is represented by the symbol @code{t}. By default, the
|
|
remaining two are represented, respectively, by the symbols
|
|
@code{:null} and @code{:false}.
|
|
|
|
@item
|
|
JSON only has floating-point numbers. They can represent both Lisp
|
|
integers and Lisp floating-point numbers.
|
|
|
|
@item
|
|
JSON strings are always Unicode strings encoded in UTF-8. Lisp
|
|
strings can contain non-Unicode characters.
|
|
|
|
@item
|
|
JSON has only one sequence type, the array. JSON arrays are
|
|
represented using Lisp vectors.
|
|
|
|
@item
|
|
JSON has only one map type, the object. JSON objects are represented
|
|
using Lisp hashtables, alists or plists. When an alist or plist
|
|
contains several elements with the same key, Emacs uses only the first
|
|
element for serialization, in accordance with the behavior of
|
|
@code{assq}.
|
|
@end itemize
|
|
|
|
@noindent
|
|
Note that @code{nil}, being both a valid alist and a valid plist,
|
|
represents @code{@{@}}, the empty JSON object; not @code{null},
|
|
@code{false}, or an empty array, all of which are different JSON
|
|
values.
|
|
|
|
If some Lisp object can't be represented in JSON, the serialization
|
|
functions will signal an error of type @code{wrong-type-argument}.
|
|
The parsing functions can also signal the following errors:
|
|
|
|
@table @code
|
|
@item json-unavailable
|
|
Signaled when the parsing library isn't available.
|
|
|
|
@item json-end-of-file
|
|
Signaled when encountering a premature end of the input text.
|
|
|
|
@item json-trailing-content
|
|
Signaled when encountering unexpected input after the first JSON
|
|
object parsed.
|
|
|
|
@item json-parse-error
|
|
Signaled when encountering invalid JSON syntax.
|
|
@end table
|
|
|
|
Top-level values and the subobjects within these top-level values
|
|
can be serialized to JSON@. Likewise, the parsing functions will
|
|
return any of the possible types described above.
|
|
|
|
@defun json-serialize object &rest args
|
|
This function returns a new Lisp unibyte string which contains the JSON
|
|
representation of @var{object}. The argument @var{args} is a list of
|
|
keyword/argument pairs. The following keywords are accepted:
|
|
|
|
@table @code
|
|
@item :null-object
|
|
The value decides which Lisp object to use to represent the JSON
|
|
keyword @code{null}. It defaults to the symbol @code{:null}.
|
|
|
|
@item :false-object
|
|
The value decides which Lisp object to use to represent the JSON
|
|
keyword @code{false}. It defaults to the symbol @code{:false}.
|
|
@end table
|
|
|
|
@end defun
|
|
|
|
@defun json-insert object &rest args
|
|
This function inserts the JSON representation of @var{object} into the
|
|
current buffer before point. The argument @var{args} are interpreted
|
|
as in @code{json-serialize}.
|
|
@end defun
|
|
|
|
@defun json-parse-string string &rest args
|
|
This function parses the JSON value in @var{string}, which must be a
|
|
Lisp string. If @var{string} doesn't contain a valid JSON object,
|
|
this function signals the @code{json-parse-error} error.
|
|
|
|
The argument @var{args} is a list of keyword/argument pairs. The
|
|
following keywords are accepted:
|
|
|
|
@table @code
|
|
@item :object-type
|
|
The value decides which Lisp object to use for representing the
|
|
key-value mappings of a JSON object. It can be either
|
|
@code{hash-table}, the default, to make hashtables with strings as
|
|
keys; @code{alist} to use alists with symbols as keys; or @code{plist}
|
|
to use plists with keyword symbols as keys.
|
|
|
|
@item :array-type
|
|
The value decides which Lisp object to use for representing a JSON
|
|
array. It can be either @code{array}, the default, to use Lisp
|
|
arrays; or @code{list} to use lists.
|
|
|
|
@item :null-object
|
|
The value decides which Lisp object to use to represent the JSON
|
|
keyword @code{null}. It defaults to the symbol @code{:null}.
|
|
|
|
@item :false-object
|
|
The value decides which Lisp object to use to represent the JSON
|
|
keyword @code{false}. It defaults to the symbol @code{:false}.
|
|
@end table
|
|
|
|
@end defun
|
|
|
|
@defun json-parse-buffer &rest args
|
|
This function reads the next JSON value from the current buffer,
|
|
starting at point. It moves point to the position immediately after
|
|
the value if contains a valid JSON object; otherwise it signals the
|
|
@code{json-parse-error} error and doesn't move point. The arguments
|
|
@var{args} are interpreted as in @code{json-parse-string}.
|
|
@end defun
|
|
|
|
@node JSONRPC
|
|
@section JSONRPC communication
|
|
@cindex JSON remote procedure call protocol
|
|
@cindex JSONRPC
|
|
|
|
The @code{jsonrpc} library implements the @acronym{JSONRPC}
|
|
specification, version 2.0, as it is described in
|
|
@uref{https://www.jsonrpc.org/}. As the name suggests, JSONRPC is a
|
|
generic @dfn{Remote Procedure Call} protocol designed around
|
|
@acronym{JSON} objects, which you can convert to and from Lisp objects
|
|
(@pxref{Parsing JSON}).
|
|
|
|
@menu
|
|
* JSONRPC Overview::
|
|
* Process-based JSONRPC connections::
|
|
* JSONRPC JSON object format::
|
|
* JSONRPC deferred requests::
|
|
@end menu
|
|
|
|
@node JSONRPC Overview
|
|
@subsection Overview
|
|
|
|
Quoting from the @uref{https://www.jsonrpc.org/, spec}, JSONRPC "is
|
|
transport agnostic in that the concepts can be used within the same
|
|
process, over sockets, over http, or in many various message passing
|
|
environments."
|
|
|
|
@findex jsonrpc-connection
|
|
To model this agnosticism, the @code{jsonrpc} library uses objects of
|
|
a @code{jsonrpc-connection} class, which represent a connection to a
|
|
remote JSON endpoint (for details on Emacs's object system,
|
|
@pxref{Top,EIEIO,,eieio,EIEIO}). In modern object-oriented parlance,
|
|
this class is ``abstract'', i.e.@: the actual class of a useful
|
|
connection object is always a subclass of @code{jsonrpc-connection}.
|
|
Nevertheless, we can define two distinct APIs around the
|
|
@code{jsonrpc-connection} class:
|
|
|
|
@cindex JSONRPC application interfaces
|
|
@enumerate
|
|
|
|
@item An API for building JSONRPC applications
|
|
|
|
@findex :request-dispatcher
|
|
@findex :notification-dispatcher
|
|
@findex jsonrpc-notify
|
|
@findex jsonrpc-request
|
|
@findex jsonrpc-async-request
|
|
In this scenario, a new aspiring JSONRPC-based application selects a
|
|
concrete subclass of @code{jsonrpc-connection} that provides the
|
|
transport for the JSONRPC messages to be exchanged between endpoints.
|
|
|
|
The application creates objects of that subclass using
|
|
@code{make-instance}. To initiate a contact to a remote endpoint, the
|
|
application passes this object to the functions such as
|
|
@code{jsonrpc-notify}, @code{jsonrpc-request}, or
|
|
@code{jsonrpc-async-request}.
|
|
|
|
For handling remotely initiated contacts, which generally come in
|
|
asynchronously, the @code{make-instance} instantiation should
|
|
initialize it the @code{:request-dispatcher} and
|
|
@code{:notification-dispatcher} EIEIO keyword arguments. These are
|
|
both functions of 3 arguments: the connection object; a symbol naming
|
|
the JSONRPC method invoked remotely; and a JSONRPC @code{params}
|
|
object.
|
|
|
|
@findex jsonrpc-error
|
|
The function passed as @code{:request-dispatcher} is responsible for
|
|
handling the remote endpoint's requests, which expect a reply from the
|
|
local endpoint (in this case, the application you're building).
|
|
Inside that function, you may either return locally (a regular return)
|
|
or non-locally (throw an error). Both exits from the request
|
|
dispatcher cause a reply to the remote endpoint's request to be sent
|
|
through the transport.
|
|
|
|
A regular return determines a success response, and the return value
|
|
must be a Lisp object that can be serialized as JSON (@pxref{Parsing
|
|
JSON}). The result is forwarded to the server as the JSONRPC
|
|
@code{result} object. A non-local return, achieved by calling the
|
|
function @code{jsonrpc-error}, causes an error response to be sent to
|
|
the server. The details of the accompanying JSONRPC @code{error}
|
|
object are filled out with whatever was passed to
|
|
@code{jsonrpc-error}. A non-local return triggered by an unexpected
|
|
error of any other type also causes an error response to be sent
|
|
(unless you have set @code{debug-on-error}, in which case this calls
|
|
the Lisp debugger, @pxref{Error Debugging}).
|
|
|
|
@findex jsonrpc-convert-to-endpoint
|
|
@findex jsonrpc-convert-from-endpoint
|
|
It's possible to use the @code{jsonrpc} library to build applications
|
|
based on transport protocols that can be described as
|
|
``quasi-JSONRPC''. These are similar, but not quite identical to
|
|
JSONRPC, such as the @uref{https://www.jsonrpc.org/, DAP (Debug
|
|
Adapter Protocol)}. These protocols also define request, response and
|
|
notification messages but the format is not quite the same as JSONRPC.
|
|
The generic functions @code{jsonrpc-convert-to-endpoint} and
|
|
@code{jsonrpc-convert-from-endpoint} can be customized for converting
|
|
between the internal representation of JSONRPC and whatever the
|
|
endpoint accepts (@pxref{Generic Functions}).
|
|
|
|
@item An API for building JSONRPC transports
|
|
|
|
In this scenario, @code{jsonrpc-connection} is sub-classed to implement
|
|
a different underlying transport strategy (for details on how to
|
|
subclass, see @ref{Inheritance,Inheritance,,eieio}.). Users of the
|
|
application-building interface can then instantiate objects of this
|
|
concrete class (using the @code{make-instance} function) and connect
|
|
to JSONRPC endpoints using that strategy. See @ref{Process-based
|
|
JSONRPC connections} for a built-in transport implementation.
|
|
|
|
This API has mandatory and optional parts.
|
|
|
|
@findex jsonrpc-connection-send
|
|
To allow its users to initiate JSONRPC contacts (notifications or
|
|
requests) or reply to endpoint requests, the new transport
|
|
implementation must equip the @code{jsonrpc-connection-send} generic
|
|
function with a specialization for the new subclass
|
|
(@pxref{Generic Functions}). This generic function is called
|
|
automatically by primitives such as @code{jsonrpc-request} and
|
|
@code{jsonrpc-notify}. The specialization should ensure that the
|
|
message described in the argument list is sent through whatever
|
|
underlying communication mechanism (a.k.a.@: ``wire'') is used by the
|
|
new transport to talk to endpoints. This ``wire'' may be a network
|
|
socket, a serial interface, an HTTP connection, etc.
|
|
|
|
@findex jsonrpc-connection-receive
|
|
Likewise, for handling the three types of remote contacts (requests,
|
|
notifications, and responses to local requests), the transport
|
|
implementation must arrange for the function
|
|
@code{jsonrpc-connection-receive} to be called from Elisp after
|
|
noticing some data on the ``wire'' that can be used to craft a JSONRPC
|
|
(or quasi-JSONRPC) message.
|
|
|
|
@findex jsonrpc-shutdown
|
|
@findex jsonrpc-running-p
|
|
Finally, and optionally, the @code{jsonrpc-connection} subclass should
|
|
add specializations to the @code{jsonrpc-shutdown} and
|
|
@code{jsonrpc-running-p} generic functions if these concepts apply to
|
|
the transport. The specialization of @code{jsonrpc-shutdown} should
|
|
ensure the release of any system resources (e.g.@: processes, timers,
|
|
etc.) used to listen for messages on the wire. The specialization of
|
|
@code{jsonrpc-running-p} should tell if these resources are still
|
|
active or have already been released (via @code{jsonrpc-shutdown} or
|
|
otherwise).
|
|
|
|
@end enumerate
|
|
|
|
@node Process-based JSONRPC connections
|
|
@subsection Process-based JSONRPC connections
|
|
@cindex JSONRPC process-based connections
|
|
|
|
@findex jsonrpc-process-connection
|
|
For convenience, the @code{jsonrpc} library comes with a built-in
|
|
@code{jsonrpc-process-connection} transport implementation that can
|
|
talk to local subprocesses (using the standard input and standard
|
|
output); or TCP hosts (using sockets); or any other remote endpoint
|
|
that Emacs's process object can represent (@pxref{Processes}).
|
|
|
|
Using this transport, the JSONRPC messages are encoded on the wire as
|
|
plain text and prefaced by some basic HTTP-style enveloping headers,
|
|
such as ``Content-Length''.
|
|
|
|
For an example of an application using this transport scheme on top of
|
|
JSONRPC, see the
|
|
@uref{https://microsoft.github.io/language-server-protocol/specification,
|
|
Language Server Protocol}.
|
|
|
|
@cindex JSONRPC connection initargs
|
|
Along with the mandatory @code{:request-dispatcher} and
|
|
@code{:notification-dispatcher} initargs, users of the
|
|
@code{jsonrpc-process-connection} class should pass the following
|
|
initargs as keyword-value pairs to @code{make-instance}:
|
|
|
|
@table @code
|
|
@item :process
|
|
Value must be a live process object or a function of no arguments
|
|
producing one such object. If passed a process object, the object is
|
|
expected to contain a pre-established connection; otherwise, the
|
|
function is called immediately after the object is made.
|
|
|
|
@item :on-shutdown
|
|
Value must be a function of a single argument, the
|
|
@code{jsonrpc-process-connection} object. The function is called
|
|
after the underlying process object has been deleted (either
|
|
deliberately by @code{jsonrpc-shutdown}, or unexpectedly, because of
|
|
some external cause).
|
|
@end table
|
|
|
|
@node JSONRPC JSON object format
|
|
@subsection JSONRPC JSON object format
|
|
@cindex JSONRPC object format
|
|
|
|
JSONRPC JSON objects are exchanged as Lisp plists (@pxref{Property
|
|
Lists}): JSON-compatible plists are handed to the dispatcher functions
|
|
and, likewise, JSON-compatible plists should be given to
|
|
@code{jsonrpc-notify}, @code{jsonrpc-request}, and
|
|
@code{jsonrpc-async-request}.
|
|
|
|
@findex jsonrpc-lambda
|
|
To facilitate handling plists, this library makes liberal use of
|
|
@code{cl-lib} library (@pxref{Top,cl-lib,,cl,Common Lisp Extensions
|
|
for GNU Emacs Lisp}) and suggests (but doesn't force) its clients to
|
|
do the same. A macro @code{jsonrpc-lambda} can be used to create a
|
|
lambda for destructuring a JSON-object like in this example:
|
|
|
|
@example
|
|
(jsonrpc-async-request
|
|
myproc :frobnicate `(:foo "trix")
|
|
:success-fn (jsonrpc-lambda (&key bar baz &allow-other-keys)
|
|
(message "Server replied back with %s and %s!"
|
|
bar baz))
|
|
:error-fn (jsonrpc-lambda (&key code message _data)
|
|
(message "Sadly, server reports %s: %s"
|
|
code message)))
|
|
@end example
|
|
|
|
@node JSONRPC deferred requests
|
|
@subsection Deferred JSONRPC requests
|
|
@cindex JSONRPC deferred requests
|
|
|
|
In many @acronym{RPC} situations, synchronization between the two
|
|
communicating endpoints is a matter of correctly designing the RPC
|
|
application: when synchronization is needed, requests (which are
|
|
blocking) should be used; when it isn't, notifications should suffice.
|
|
However, when Emacs acts as one of these endpoints, asynchronous
|
|
events (e.g. timer- or process-related) may be triggered while there
|
|
is still uncertainty about the state of the remote endpoint.
|
|
Furthermore, acting on these events may only sometimes demand
|
|
synchronization, depending on the event's specific nature.
|
|
|
|
@findex :deferred@r{, JSONRPC keyword}
|
|
The @code{:deferred} keyword argument to @code{jsonrpc-request} and
|
|
@code{jsonrpc-async-request} is designed to let the caller indicate
|
|
that the specific request needs synchronization and its actual
|
|
issuance may be delayed to the future, until some condition is
|
|
satisfied. Specifying @code{:deferred} for a request doesn't mean it
|
|
@emph{will} be delayed, only that it @emph{can} be. If the request
|
|
isn't sent immediately, @code{jsonrpc} will make renewed efforts to
|
|
send it at certain key times during communication, such as when
|
|
receiving or sending other messages to the endpoint.
|
|
|
|
@findex jsonrpc-connection-ready-p
|
|
Before any attempt to send the request, the application-specific
|
|
conditions are checked. Since the @code{jsonrpc} library can't know
|
|
what these conditions are, the program can use the
|
|
@code{jsonrpc-connection-ready-p} generic function (@pxref{Generic
|
|
Functions}) to specify them. The default method for this function
|
|
returns @code{t}, but you can add overriding methods that return
|
|
@code{nil} in some situations, based on the arguments passed to it,
|
|
which are the @code{jsonrpc-connection} object (@pxref{JSONRPC
|
|
Overview}) and whichever value you passed as the @code{:deferred}
|
|
keyword argument.
|
|
|
|
@node Atomic Changes
|
|
@section Atomic Change Groups
|
|
@cindex atomic changes
|
|
|
|
In database terminology, an @dfn{atomic} change is an indivisible
|
|
change---it can succeed entirely or it can fail entirely, but it
|
|
cannot partly succeed. A Lisp program can make a series of changes to
|
|
one or several buffers as an @dfn{atomic change group}, meaning that
|
|
either the entire series of changes will be installed in their buffers
|
|
or, in case of an error, none of them will be.
|
|
|
|
To do this for one buffer, the one already current, simply write a
|
|
call to @code{atomic-change-group} around the code that makes the
|
|
changes, like this:
|
|
|
|
@example
|
|
(atomic-change-group
|
|
(insert foo)
|
|
(delete-region x y))
|
|
@end example
|
|
|
|
@noindent
|
|
If an error (or other nonlocal exit) occurs inside the body of
|
|
@code{atomic-change-group}, it unmakes all the changes in that buffer
|
|
that were during the execution of the body. This kind of change group
|
|
has no effect on any other buffers---any such changes remain.
|
|
|
|
If you need something more sophisticated, such as to make changes in
|
|
various buffers constitute one atomic group, you must directly call
|
|
lower-level functions that @code{atomic-change-group} uses.
|
|
|
|
@defun prepare-change-group &optional buffer
|
|
This function sets up a change group for buffer @var{buffer}, which
|
|
defaults to the current buffer. It returns a handle that
|
|
represents the change group. You must use this handle to activate the
|
|
change group and subsequently to finish it.
|
|
@end defun
|
|
|
|
To use the change group, you must @dfn{activate} it. You must do
|
|
this before making any changes in the text of @var{buffer}.
|
|
|
|
@defun activate-change-group handle
|
|
This function activates the change group that @var{handle} designates.
|
|
@end defun
|
|
|
|
After you activate the change group, any changes you make in that
|
|
buffer become part of it. Once you have made all the desired changes
|
|
in the buffer, you must @dfn{finish} the change group. There are two
|
|
ways to do this: you can either accept (and finalize) all the changes,
|
|
or cancel them all.
|
|
|
|
@defun accept-change-group handle
|
|
This function accepts all the changes in the change group specified by
|
|
@var{handle}, making them final.
|
|
@end defun
|
|
|
|
@defun cancel-change-group handle
|
|
This function cancels and undoes all the changes in the change group
|
|
specified by @var{handle}.
|
|
@end defun
|
|
|
|
You can cause some or all of the changes in a change group to be
|
|
considered as a single unit for the purposes of the @code{undo}
|
|
commands (@pxref{Undo}) by using @code{undo-amalgamate-change-group}.
|
|
|
|
@defun undo-amalgamate-change-group
|
|
Amalgamate all the changes made in the change-group since the state
|
|
identified by @var{handle}. This function removes all undo boundaries
|
|
between undo records of changes since the state described by
|
|
@var{handle}. Usually, @var{handle} is the handle returned by
|
|
@code{prepare-change-group}, in which case all the changes since the
|
|
beginning of the change-group are amalgamated into a single undo unit.
|
|
@end defun
|
|
|
|
Your code should use @code{unwind-protect} to make sure the group is
|
|
always finished. The call to @code{activate-change-group} should be
|
|
inside the @code{unwind-protect}, in case the user types @kbd{C-g}
|
|
just after it runs. (This is one reason why
|
|
@code{prepare-change-group} and @code{activate-change-group} are
|
|
separate functions, because normally you would call
|
|
@code{prepare-change-group} before the start of that
|
|
@code{unwind-protect}.) Once you finish the group, don't use the
|
|
handle again---in particular, don't try to finish the same group
|
|
twice.
|
|
|
|
To make a multibuffer change group, call @code{prepare-change-group}
|
|
once for each buffer you want to cover, then use @code{nconc} to
|
|
combine the returned values, like this:
|
|
|
|
@example
|
|
(nconc (prepare-change-group buffer-1)
|
|
(prepare-change-group buffer-2))
|
|
@end example
|
|
|
|
You can then activate the multibuffer change group with a single call
|
|
to @code{activate-change-group}, and finish it with a single call to
|
|
@code{accept-change-group} or @code{cancel-change-group}.
|
|
|
|
Nested use of several change groups for the same buffer works as you
|
|
would expect. Non-nested use of change groups for the same buffer
|
|
will get Emacs confused, so don't let it happen; the first change
|
|
group you start for any given buffer should be the last one finished.
|
|
|
|
Emacs keeps track of change groups by assuming that by following
|
|
each cdr in @code{buffer-undo-list}, it will eventually arrive at the
|
|
cons it was set to at the time @code{prepare-change-group} was called.
|
|
|
|
If @code{buffer-undo-list} no longer contains that cons, Emacs will
|
|
lose track of any change groups, resulting in an error when the change
|
|
group is canceled. To avoid this, do not call any functions which
|
|
may edit the undo list in such a manner, when a change group is
|
|
active: notably, ``amalgamating'' commands such as @code{delete-char},
|
|
which call @code{undo-auto-amalgamate}.
|
|
|
|
@node Change Hooks
|
|
@section Change Hooks
|
|
@cindex change hooks
|
|
@cindex hooks for text changes
|
|
|
|
These hook variables let you arrange to take notice of changes in
|
|
buffers (or in a particular buffer, if you make them buffer-local).
|
|
See also @ref{Special Properties}, for how to detect changes to
|
|
specific parts of the text.
|
|
|
|
The functions you use in these hooks should save and restore the match
|
|
data if they do anything that uses regular expressions; otherwise, they
|
|
will interfere in bizarre ways with the editing operations that call
|
|
them.
|
|
|
|
@defvar before-change-functions
|
|
This variable holds a list of functions to call when Emacs is about to
|
|
modify a buffer. Each function gets two arguments, the beginning and
|
|
end of the region that is about to change, represented as integers.
|
|
The buffer that is about to change is always the current buffer when
|
|
the function is called.
|
|
@end defvar
|
|
|
|
@defvar after-change-functions
|
|
This variable holds a list of functions to call after Emacs modifies a
|
|
buffer. Each function receives three arguments: the beginning and end
|
|
of the region just changed, and the length of the text that existed
|
|
before the change. All three arguments are integers. The buffer that
|
|
has been changed is always the current buffer when the function is
|
|
called.
|
|
|
|
The length of the old text is the difference between the buffer
|
|
positions before and after that text as it was before the change. As
|
|
for the changed text, its length is simply the difference between the
|
|
first two arguments.
|
|
@end defvar
|
|
|
|
Output of messages into the @file{*Messages*} buffer does not call
|
|
these functions, and neither do certain internal buffer changes, such
|
|
as changes in buffers created by Emacs internally for certain jobs,
|
|
that should not be visible to Lisp programs.
|
|
|
|
The vast majority of buffer changing primitives will call
|
|
@code{before-change-functions} and @code{after-change-functions} in
|
|
balanced pairs, once for each change, where the arguments to these
|
|
hooks exactly delimit the change being made. Yet, hook functions
|
|
should not rely on this always being the case, because some complex
|
|
primitives call @code{before-change-functions} once before making
|
|
changes, and then call @code{after-change-functions} zero or more
|
|
times, depending on how many individual changes the primitive is
|
|
making. When that happens, the arguments to
|
|
@code{before-change-functions} will enclose a region in which the
|
|
individual changes are made, but won't necessarily be the minimal such
|
|
region, and the arguments to each successive call of
|
|
@code{after-change-functions} will then delimit the part of text being
|
|
changed exactly. In general, we advise using either the before- or
|
|
the after-change hook, but not both.
|
|
|
|
@defmac combine-after-change-calls body@dots{}
|
|
The macro executes @var{body} normally, but arranges to call the
|
|
after-change functions just once for a series of several changes---if
|
|
that seems safe.
|
|
|
|
If a program makes several text changes in the same area of the buffer,
|
|
using the macro @code{combine-after-change-calls} around that part of
|
|
the program can make it run considerably faster when after-change hooks
|
|
are in use. When the after-change hooks are ultimately called, the
|
|
arguments specify a portion of the buffer including all of the changes
|
|
made within the @code{combine-after-change-calls} body.
|
|
|
|
@strong{Warning:} You must not alter the values of
|
|
@code{after-change-functions} within
|
|
the body of a @code{combine-after-change-calls} form.
|
|
|
|
@strong{Warning:} If the changes you combine occur in widely scattered
|
|
parts of the buffer, this will still work, but it is not advisable,
|
|
because it may lead to inefficient behavior for some change hook
|
|
functions.
|
|
@end defmac
|
|
|
|
@defmac combine-change-calls beg end body@dots{}
|
|
This executes @var{body} normally, except any buffer changes it makes
|
|
do not trigger the calls to @code{before-change-functions} and
|
|
@code{after-change-functions}. Instead there is a single call of each
|
|
of these hooks for the region enclosed by @var{beg} and @var{end}, the
|
|
parameters supplied to @code{after-change-functions} reflecting the
|
|
changes made to the size of the region by @var{body}.
|
|
|
|
The result of this macro is the result returned by @var{body}.
|
|
|
|
This macro is useful when a function makes a possibly large number of
|
|
repetitive changes to the buffer, and the change hooks would otherwise
|
|
take a long time to run, were they to be run for each individual
|
|
buffer modification. Emacs itself uses this macro, for example, in
|
|
the commands @code{comment-region} and @code{uncomment-region}.
|
|
|
|
@strong{Warning:} You must not alter the values of
|
|
@code{before-change-functions} or @code{after-change-function} within
|
|
@var{body}.
|
|
|
|
@strong{Warning:} You must not make any buffer changes outside of the
|
|
region specified by @var{beg} and @var{end}.
|
|
@end defmac
|
|
|
|
@defvar first-change-hook
|
|
This variable is a normal hook that is run whenever a buffer is changed
|
|
that was previously in the unmodified state.
|
|
@end defvar
|
|
|
|
@defvar inhibit-modification-hooks
|
|
If this variable is non-@code{nil}, all of the change hooks are
|
|
disabled; none of them run. This affects all the hook variables
|
|
described above in this section, as well as the hooks attached to
|
|
certain special text properties (@pxref{Special Properties}) and overlay
|
|
properties (@pxref{Overlay Properties}).
|
|
|
|
Also, this variable is bound to non-@code{nil} while running those
|
|
same hook variables, so that by default modifying the buffer from
|
|
a modification hook does not cause other modification hooks to be run.
|
|
If you do want modification hooks to be run in a particular piece of
|
|
code that is itself run from a modification hook, then rebind locally
|
|
@code{inhibit-modification-hooks} to @code{nil}. However, doing this
|
|
may cause recursive calls to the modification hooks, so be sure to
|
|
prepare for that (for example, by binding some variable which tells
|
|
your hook to do nothing).
|
|
|
|
We recommend that you only bind this variable for modifications that
|
|
do not result in lasting changes to buffer text contents (for example
|
|
face changes or temporary modifications). If you need to delay change
|
|
hooks during a series of changes (typically for performance reasons),
|
|
use @code{combine-change-calls} or @code{combine-after-change-calls}
|
|
instead.
|
|
@end defvar
|
|
|
|
@menu
|
|
* Tracking changes:: Keeping track of buffer modifications.
|
|
@end menu
|
|
|
|
@node Tracking changes
|
|
@subsection Keeping track of buffer modifications
|
|
@cindex track-changes
|
|
@cindex change tracker
|
|
|
|
Using @code{before-change-functions} and @code{after-change-functions}
|
|
can be difficult in practice because of a number of pitfalls, such as
|
|
the fact that the two calls are not always properly paired, or some
|
|
calls may be missing, either because some Emacs primitives failed to
|
|
properly pair them or because of incorrect use of
|
|
@code{inhibit-modification-hooks}. Furthermore,
|
|
many restrictions apply to those hook functions, such as the fact that
|
|
they basically should never modify the current buffer, nor use an
|
|
operation that may block, and they proceed quickly because
|
|
some commands may call these hooks a large number of times.
|
|
|
|
The Track-Changes library fundamentally provides an alternative API,
|
|
built on top of those hooks. Compared to @code{after-change-functions},
|
|
the first important difference is that, instead of providing the bounds
|
|
of the change and the previous length, it provides the bounds of the
|
|
change and the actual previous content of that region. The need to
|
|
extract information from the original contents of the buffer is one of
|
|
the main reasons why some packages need to use both
|
|
@code{before-change-functions} and @code{after-change-functions} and
|
|
then try to match them up.
|
|
|
|
The second difference is that it decouples the notification of a change
|
|
from the act of processing it, and it automatically combines into
|
|
a single change operation all the changes that occur between the first
|
|
change and the actual processing. This makes it natural and easy to
|
|
process the changes at a larger granularity, such as once per command,
|
|
and eliminates most of the restrictions that apply to the usual change
|
|
hook functions, making it possible to use blocking operations or to
|
|
modify the buffer.
|
|
|
|
To start tracking changes, you have to call
|
|
@code{track-changes-register}, passing it a @var{signal} function as
|
|
argument. This returns a tracker @var{id} which is used to identify
|
|
your change tracker to the other functions of the library.
|
|
When the buffer is modified, the library calls the @var{signal}
|
|
function to inform you of that change and immediately starts
|
|
accumulating subsequent changes into a single combined change.
|
|
The @var{signal} function serves only to warn that a modification
|
|
occurred but does not receive a description of the change. Also the
|
|
library will not call it again until after you retrieved the change.
|
|
|
|
To retrieve changes, you need to call @code{track-changes-fetch}, which
|
|
provides you with the bounds of the changes accumulated since the
|
|
last call, as well as the previous content of that region. It also
|
|
``re-arms'' the @var{signal} function so that the library will call it
|
|
again after the next buffer modification.
|
|
|
|
@defun track-changes-register signal &key nobefore disjoint immediate
|
|
This function creates a new @dfn{change tracker}. Change trackers are kept
|
|
abstract, so we refer to them as mere identities, and the function thus
|
|
returns the tracker's @var{id}.
|
|
|
|
@var{signal} is a function that the library will call to notify of
|
|
a change. It will sometimes call it with a single argument and
|
|
sometimes with two. Upon the first change to the buffer since this
|
|
tracker last called @code{track-changes-fetch}, the library calls this
|
|
@var{signal} function with a single argument holding the @var{id} of
|
|
the tracker.
|
|
|
|
By default, the call to the @var{signal} function does not happen
|
|
immediately, but is instead postponed with a 0 seconds timer
|
|
(@pxref{Timers}). This is usually desired to make sure the @var{signal}
|
|
function is not called too frequently and runs in a permissive context,
|
|
freeing the client from performance concerns or worries about which
|
|
operations might be problematic. If a client wants to have more
|
|
control, they can provide a non-@code{nil} value as the @var{immediate}
|
|
argument in which case the library calls the @var{signal} function
|
|
directly from @code{after-change-functions}. Beware that it means that
|
|
the @var{signal} function has to be careful not to modify the buffer or
|
|
use operations that may block.
|
|
|
|
If you're not interested in the actual previous content of the buffer,
|
|
but are using this library only for its ability to combine many small
|
|
changes into a larger one and to delay the processing to a more
|
|
convenient time, you can specify a non-@code{nil} value for the
|
|
@var{nobefore} argument. In that case, @code{track-change-fetch}
|
|
provides you only with the length of the previous content, just like
|
|
@code{after-change-functions}. It also allows the library to save
|
|
some work.
|
|
|
|
While you may like to accumulate many small changes into larger ones,
|
|
you may not want to do that if the changes are too far apart. If you
|
|
specify a non-@code{nil} value for the @var{disjoint} argument, the library
|
|
will let you know when a change is about to occur ``far'' from the
|
|
currently pending ones by calling the @var{signal} function right away,
|
|
passing it two arguments this time: the @var{id} of the tracker, and the
|
|
number of characters that separates the upcoming change from the
|
|
already pending changes. This in itself does not prevent combining this
|
|
new change with the previous ones, so if you think the upcoming change
|
|
is indeed too far, you need to call @code{track-change-fetch}
|
|
right away.
|
|
Beware that when the @var{signal} function is called because of
|
|
a disjoint change, this happens directly from
|
|
@code{before-change-functions}, so the usual restrictions apply about
|
|
modifying the buffer or using operations that may block.
|
|
@end defun
|
|
|
|
@defun track-changes-fetch id func
|
|
This is the function that lets you find out what has changed in the
|
|
buffer. By providing the tracker @var{id} you let the library figure
|
|
out which changes have already been seen by your tracker. Instead of
|
|
returning a description of the changes, @code{track-changes-fetch} calls
|
|
the @var{func} function with that description in the form of
|
|
3 arguments: @var{beg}, @var{end}, and @var{before}, where
|
|
@code{@var{beg}..@var{end}} delimit the region that was modified and
|
|
@var{before} describes the previous content of that region.
|
|
Usually @var{before} is a string containing the previous text of the
|
|
modified region, but if you specified a non-@code{nil} @var{nobefore} argument
|
|
to @code{track-changes-register}, then it is replaced by the number of
|
|
characters of that previous text.
|
|
|
|
In case no changes occurred since the last call,
|
|
@code{track-changes-fetch} simply does not call @var{func} and returns
|
|
@code{nil}. If changes did occur, it calls @var{func} and returns the value
|
|
returned by @var{func}. But note that @var{func} is called just once
|
|
regardless of how many changes occurred: those are summarized into
|
|
a single @var{beg}/@var{end}/@var{before} triplet.
|
|
|
|
In some cases, the library is not properly notified of all changes,
|
|
for example because of a bug in the low-level C code or because of an
|
|
improper use of @code{inhibit-modification-hooks}. When it detects such
|
|
a problem, @var{func} receives a @code{@var{beg}..@var{end}} region
|
|
which covers the whole buffer and the @var{before} argument is the
|
|
symbol @code{error} to indicate that the library was unable to determine
|
|
what was changed.
|
|
|
|
Once @var{func} finishes, @code{track-changes-fetch} re-enables the
|
|
@var{signal} function so that it will be called the next time a change
|
|
occurs. This is the reason why it calls @var{func} instead of returning
|
|
a description: it lets you process the change without worrying about the
|
|
risk that the @var{signal} function gets triggered in the middle of it,
|
|
because the @var{signal} is re-enabled only after @var{func} finishes.
|
|
@end defun
|
|
|
|
@defun track-changes-unregister id
|
|
This function tells the library that the tracker @var{id} does not need
|
|
to know about buffer changes any more. Most clients will never want to
|
|
stop tracking changes, but for clients such as minor modes, it is
|
|
important to call this function when the minor mode is disabled,
|
|
otherwise the tracker will keep accumulating changes and consume more
|
|
and more resources.
|
|
@end defun
|