groff
[Top][All Lists]
Advanced

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

Re: [Groff] nop request and .tm


From: Steve Izma
Subject: Re: [Groff] nop request and .tm
Date: Tue, 12 Sep 2000 18:46:27 -0500

Thanks Werner for all the info. However, I need a few more
clarifications.

> > Is tmac.trace still under development? I'm very interested in this;
> > could you describe how I find it?

> It's part of groff already!  For example, say

>   groff -mtrace -mm ...

We're using groff 1.15 here, so I downloaded the 1.16 package and
extracted tmac.trace. However, when I test it out, the "trace enter"
message gets read as text input, whereas the "trace ext" message goes
through to stderr. Am I missing something? Are there hooks in 1.16
that are needed to prevent this? I like the idea though.

> With `interning' I mean that groff has no way to store macros in a
> context-independent way.  For example, TeX no longer depends on the
> escape value after a macro has been defined:

>   \def\foo#1{\texttt{#1}}

>   \begingroup
>     \catcode `|=0
>     \carcode `\\=12
>     |foo{bar}
>   |endgroup

> The macro `texttt' in `foo' can be executed successfully even if the
> escape character has been changed to `|'.  A similar thing won't work
> with groff.

I see what you mean here and this is what I was wondering about.

> After looking at the source code a bit more closely I now believe that
> implementing a `return' request isn't that difficult (and James Clark
> has already added it to troff's TODO list) -- basically it is only
> necessary to pop the current macro off the input stack.
> Unfortunately, I'm not that intimate with the code yet to do that
> easily...

Nonetheless, this sounds promising.

> > I would use this in places where I want to
> > call a macro without having to deal with the whitespace that gets
> > added at line endings (I am mostly dealing with situations where I
> > want groff to be a filter for text that contains tags or some
> > non-troff codes to begin with, so it is much extra work to add \c to
> > the ends of lines); e.g.:
> > 
> > This is a line of text.<superscript>1</superscript>

> Try this:

> ----------------------------------------------------------------------
> .de sup
> \c
> \fR\s[(u;\\n[.s]z*2/3)]\u\c
> ..
> .
> .de /sup
> \c
> \d\s0\fP\c
> ..
> .
> This is a line of text.\*[sup]1\*[/sup]
> ----------------------------------------------------------------------

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)?

> --- Forwarded mail from Ralph Corderoy <address@hidden>
> >
> > BTW, to support this better I will introduce three new commands:
> >
> >   .ecs xx      Save current escape character.
> >   .ecr xx      Restore escape character saved with .ecs

> Can't \e be used instead?

>     .ds x \e
>     .ds y @
>     .ec \*[y]
>     escape char is @e
>     .ec \*[x]
>     escape char is \e

> Why the special commands?  Are you worried about not knowing the
> current escape character when you want to save it?  If so, isn't just a
> convention that it is always backslash when source macro packages, etc.
> If you change it locally you should change it back before using others
> code.

> I'm after a little more understanding as to why new commands are
> necessary.

I think that Werner's suggested commands improve our ability to write
structured macros. They allow you to write code that doesn't need to
know either what the current escape character is or what the name of
any string is that represents it. This makes the code more reusable or
modular -- you can have a separate macro module that does things with
the escape character (and presumably needs to do so in order to perform some
special function) and that module can be called by other macros.
These macros then do not need to pass special information about the escape
character to that module.

It's similar reasoning to why troff has other read-only registers
for point size, leading, and other current parameters.

-- 
Steve Izma,                               (519) 884-0710 ext. 6125
    Wilfrid Laurier University Press      FAX: (519) 725-1399
    Waterloo, Ont., Canada N2L 3C5        address@hidden

reply via email to

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