117 lines
4.9 KiB
HTML
117 lines
4.9 KiB
HTML
<html>
|
|
<head>
|
|
<!-- This file has been generated by unroff 1.0, 03/21/96 19:29:44. -->
|
|
<!-- Do not edit! -->
|
|
<link rev="made" href="mailto:net@informatik.uni-bremen.de">
|
|
<title>unroff Programmer's Manual, section 7.</title>
|
|
</head><body>
|
|
<h2><a name="section7">7.</a> <tt> </tt>How Troff Input is Processed
|
|
</h2>
|
|
<p>
|
|
 <tt> </tt> <tt> </tt> <tt> </tt>To be able to write non-trivial event handling procedures, it helps
|
|
to have a look at how troff input is processed, especially since
|
|
the parser of
|
|
<i>unroff
|
|
</i>works somewhat differently than ordinary troff.<tt> </tt>
|
|
In particular, the parser cannot blindly rescan the result of
|
|
handlers for escape sequences or special characters, as these
|
|
handlers will probably generate text in the
|
|
<i>target language
|
|
</i>that cannot be interpreted as troff input any longer.<tt> </tt>
|
|
Here is a brief overview of the parsing process.<tt> </tt>
|
|
<p>
|
|
 <tt> </tt> <tt> </tt> <tt> </tt>Each input line is first scanned for references to troff strings and
|
|
number registers (this scanning pass will later be referred to as the
|
|
``expansion phase'').<tt> </tt>
|
|
For each `\*' or `\n' sequence found in the input line,
|
|
<i>unroff
|
|
</i>checks whether a handler for the string or number register has
|
|
been defined with
|
|
<i>defstring
|
|
</i>or
|
|
<i>defnumreg</i>,
|
|
and if this is the case, replaces the string or number register
|
|
reference by the result (or value) of the handler.<tt> </tt>
|
|
Otherwise, if a handler for the escape sequence `\*' or `\n'
|
|
proper has been defined, that handler is called.<tt> </tt>
|
|
Otherwise the reference is left untouched and scanning resumes
|
|
behind it<a href="m-notes.html#footnote1">[note 1]</a>
|
|
.<tt> </tt>
|
|
Comments are recognized in this phase, too, by calling the handler
|
|
for the `\"' escape sequence if there is one.<tt> </tt>
|
|
<p>
|
|
 <tt> </tt> <tt> </tt> <tt> </tt>Next, the parser checks whether the result of the first phase
|
|
is a request or macro invocation (that is, begins with a period
|
|
or an apostrophe).<tt> </tt>
|
|
If this is the case, the arguments are parsed mimicking the
|
|
behavior of ordinary troff.<tt> </tt>
|
|
The rules for macro arguments are employed if
|
|
a handler has been defined
|
|
for the token after the period with
|
|
<i>defmacro</i>,
|
|
else the rules for requests are used.<tt> </tt>
|
|
The handler for the macro or request is then used, or applied
|
|
to the arguments if it is a procedure.<tt> </tt>
|
|
<p>
|
|
 <tt> </tt> <tt> </tt> <tt> </tt>If the input line does not contain a request or macro invocation,
|
|
it is scanned a second time to take care of escape sequences
|
|
and special characters (for lack of a better term, we will call
|
|
this phase ``escape parsing'').<tt> </tt>
|
|
Every escape character reference, special character, and inline
|
|
equation is replaced by the result (or value) of the event
|
|
handler registered for it, or left in place if there is no handler.<tt> </tt>
|
|
Character translations defined by means of
|
|
<i>defchar
|
|
</i>are also executed in this phase.<tt> </tt>
|
|
<p>
|
|
 <tt> </tt> <tt> </tt> <tt> </tt>Finally, the result of the escape parsing phase or of the request or
|
|
macro invocation is checked whether it constitutes the end of a
|
|
sentence, and if so, the handler for this event is called
|
|
(actually, in the former case, the check is applied before
|
|
<i>and
|
|
</i>after the escape parsing and must succeed both times).<tt> </tt>
|
|
As the final step the line is output, and any handlers for the
|
|
<i>line
|
|
</i>event are invoked.<tt> </tt>
|
|
<p>
|
|
 <tt> </tt> <tt> </tt> <tt> </tt>An important thing to note is that the arguments passed to a handler
|
|
defined for a request or macro are not scanned for escape sequences
|
|
and special characters.<tt> </tt>
|
|
Therefore event procedures must explicitly parse their arguments if
|
|
desired by calling the Scheme primitive
|
|
<a href="m-8.html#.parse"><i>parse</i></a>
|
|
(which will be described in the next section).<tt> </tt>
|
|
Consider, for example, an event procedure associated with a
|
|
macro ``IP'':
|
|
<dl><dt><dd>
|
|
<pre>
|
|
(defmacro 'IP
|
|
(lambda (IP tag . indent)
|
|
...))
|
|
</pre>
|
|
</dl>
|
|
and a call to the macro with an argument containing a
|
|
special character:
|
|
<dl><dt><dd>
|
|
<pre>
|
|
.IP \(bu
|
|
</pre>
|
|
</dl>
|
|
As the argument to the event procedure is only scanned for
|
|
strings and number registers, the variable
|
|
<i>tag
|
|
</i>will be bound to the string ``\(bu''.<tt> </tt>
|
|
Applying
|
|
<i>parse
|
|
</i>to the argument will turn it into whatever is the target language
|
|
representation for the special character ``\(bu'' (that is, the
|
|
result of the event handler for the special character).<tt> </tt>
|
|
Whether or not arguments will have to be parsed depends on the
|
|
particular request or macro; the procedure implementing the request
|
|
``.tm'', for instance, will print its ``raw'' argument (a sample
|
|
event handler for the request ``.tm'' is supplied by
|
|
<i>unroff</i>).<tt> </tt>
|
|
<p><hr>
|
|
Markup created by <em>unroff</em> 1.0, <tt> </tt> <tt> </tt>March 21, 1996, <tt> </tt> <tt> </tt>net@informatik.uni-bremen.de</body>
|
|
</html>
|