groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Groff] nop request and .tm


From: Ted Harding
Subject: Re: [Groff] nop request and .tm
Date: Wed, 13 Sep 2000 11:19:36 +0100 (BST)

On 12-Sep-00 Steve Izma wrote:
> This explains for me the interoperability (I guess that's what it can
> be called) of the request and string syntax. But to be useable in this
> way (both inline and as a request on line by itself) everything
> contained in the definition must be inline code -- strings or escape
> sequences. From my testing, I can't put conditional statements, for
> example, in the definition; they are sent to the output as strings of
> text.
> 
> So I think another way of stating my question is: why does troff make
> a distinction between the excape syntax (e.g., "\*", or just plain
> "\") and the request syntax ("." or "'", i.e., the control character)?

Sorry, I've been too occupied lately to follow all the ramifications
of this discussion, but it seems to me that there's some misconception
about strings and macros.

Fundamentally, a string (defined by .ds) and a macro (defined by .de)
are essentially the same once defined: stuff which will be interpolated
in the input stream when invoked. Likewise diversions. In that sense
it's ALL inline code.

All these things share name space and can be invoked using either macro
or string invocation syntax. That is how troff _is_, and changing
anything essential in that would involve a complete re-conceptualisation
of troff. If TeX is different, then so be it.

The main differences are in how they are defined (.ds versus .de),
in what can be defined (you can't define a multi-line string) and
in how they can be invoked: you can't use a string invocation \*[...]
with arguments (though it has been lurking in an implicit TODO to
implement this, e.g. as \*[String (arglist)] but this has to get past
the "no spaces in escape names" trap), whereas the macro invocation
mechanism looks for arguments.

But you can invoke StringName with arguments as
.StringName arguments

and you can interpolate MacroName as ... \*[MacroName] ... without
arguments -- conditional lines and all.

Consider the following, which exemplifies some of the possibilities
(and some of the points to watch):

    .ds String This string says \\$*
    .LP
    \&.String:
    .LP
    Usage as String: What does \fB\*[String]\fP say?
    .LP
    Usage as Macro:
    .String HELLO WORLD
    !
    .sp 1
    .de Macro
    \c
    .ie !\\n[.$] This Macro Has No Arguments
    .el This Macro Has \\n[.$] Arguments
    ..
    .LP
    \&.Macro:
    .LP
    Usage as Macro:
    .Macro one two three
    .LP
    Usage as String: \*[Macro]
    .sp 1
    And so on

(Use ms macros for this). You should get:

    .String:
    Usage as String: What does This string says  say?
    Usage as Macro: This string says HELLO WORLD!

    .Macro:
    Usage as Macro: This Macro Has 3 Arguments
    Usage as String: This Macro Has No Arguments

    And so on

NOTE:
1. The use of ! (or a blank line would do) on the next line
   after .String -- this is because ".ds String" creates String
   without the newline at the end of the defining line. Therefore
   when String gets interpolated there is no newline and so the
   apparently next input line is in fact a continuation of the
   same line -- just like \ at the end of a line -- so you would
   get "HELLO WORLD.sp 1" instead.

2. Somewhat similarly, note the \c as the first line of the
   macro Macro: when invoked as \*[Macro] its first line is
   interpolated at the position of the interpolation, so
   without the \c the input line would continue with ".if",
   which is not what you want.
   (Of course you could evade this by typing "\*[Macro]" at the
   start of the next line; but this would be yet another item
   whose interpretation depends on where the user types it: it's
   bad enough remembering to make sure that "." occurs at the
   start of a line only when you really mean to invoke a macro).

As to changing the escape character: I have to confess that I've
never got into a situation where that was called for, so I'm a bit
out of that part of the discussion. However, for those who have
that concern, what are the views on using "\E" (escape character,
whatever it may be, not interpreted in copy mode)?

Best wishes to all,
Ted.

--------------------------------------------------------------------
E-Mail: (Ted Harding) <address@hidden>
Fax-to-email: +44 (0)870 284 7749
Date: 13-Sep-00                                       Time: 11:19:36
------------------------------ XFMail ------------------------------

reply via email to

[Prev in Thread] Current Thread [Next in Thread]