594 |
@section Parsing Balanced Expressions |
@section Parsing Balanced Expressions |
595 |
|
|
596 |
Here are several functions for parsing and scanning balanced |
Here are several functions for parsing and scanning balanced |
597 |
expressions, also known as @dfn{sexps}, in which parentheses match in |
expressions, also known as @dfn{sexps}. Basically, a sexp is either a |
598 |
pairs. The syntax table controls the interpretation of characters, so |
balanced parenthetical grouping, or a symbol name (a sequence of |
599 |
these functions can be used for Lisp expressions when in Lisp mode and |
characters whose syntax is either word constituent or symbol |
600 |
for C expressions when in C mode. @xref{List Motion}, for convenient |
constituent). However, characters whose syntax is expression prefix |
601 |
|
are treated as part of the sexp if they appear next to it. |
602 |
|
|
603 |
|
The syntax table controls the interpretation of characters, so these |
604 |
|
functions can be used for Lisp expressions when in Lisp mode and for C |
605 |
|
expressions when in C mode. @xref{List Motion}, for convenient |
606 |
higher-level functions for moving over balanced expressions. |
higher-level functions for moving over balanced expressions. |
607 |
|
|
608 |
A syntax table only describes how each character changes the state of |
A syntax table only describes how each character changes the state |
609 |
the parser, rather than describing the state itself. For example, a string |
of the parser, rather than describing the state itself. For example, |
610 |
delimiter character toggles the parser state between ``in-string'' and |
a string delimiter character toggles the parser state between |
611 |
``in-code'' but the characters inside the string do not have any particular |
``in-string'' and ``in-code'' but the characters inside the string do |
612 |
syntax to identify them as such. |
not have any particular syntax to identify them as such. For example |
613 |
|
(note that 15 is the syntax code for generic string delimiters), |
|
For example (note: 15 is the syntax-code of generic string delimiters): |
|
614 |
|
|
615 |
@example |
@example |
616 |
(put-text-property 1 9 'syntax-table '(15 . nil)) |
(put-text-property 1 9 'syntax-table '(15 . nil)) |
617 |
@end example |
@end example |
618 |
|
|
619 |
|
@noindent |
620 |
does not tell Emacs that the first eight chars of the current buffer |
does not tell Emacs that the first eight chars of the current buffer |
621 |
are a string, but rather that they are all string delimiters and thus |
are a string, but rather that they are all string delimiters. As a |
622 |
Emacs should treat them as four adjacent empty strings. |
result, Emacs treats them as four consecutive empty string constants. |
623 |
|
|
624 |
The state of the parser is transient (i.e. not stored in the buffer for |
Every time you use the parser, you specify it a starting state as |
625 |
example). Instead, every time the parser is used, it is given not just |
well as a starting position. If you omit the starting state, the |
626 |
a starting position but a starting state. If the starting state is not |
default is ``top level in parenthesis structure,'' as it would be at |
627 |
specified explicitly, Emacs assumes we are at the top level of parenthesis |
the beginning of a function definition. (This is the case for |
628 |
structure, such as the beginning of a function definition (this is the case |
@code{forward-sexp}, which blindly assumes that the starting point is |
629 |
for @code{forward-sexp} which blindly assumes that the starting point is in |
in such a state.) |
|
such a state.) |
|
630 |
|
|
631 |
@defun parse-partial-sexp start limit &optional target-depth stop-before state stop-comment |
@defun parse-partial-sexp start limit &optional target-depth stop-before state stop-comment |
632 |
This function parses a sexp in the current buffer starting at |
This function parses a sexp in the current buffer starting at |