Re: [Groff] nop request and .tm

[Steve Izma]

> `.print' seems to be an excellent name!

> Just to introduce another alternative: What do you think about the
> name `.id', based on the idea of an `identity' mapping?

I don't quite understand the idea of identity mapping. Do you mean in
the sense of mapping input directly to output?

> .... I will introduce three new commands:

>   .ecs xx      Save current escape character.
>   .ecr xx      Restore escape character saved with .ecs

>   .dei xx yy   Define indirect.  This is equivalent to

>                .ds xx ...
>                .ds yy ...
>                .de \*[xx] \*[yy]

> The reason for the first two commands is rather obvious.  It gives
> macro packages a chance to restore the previous escape character

This seems okay to me.

> The second command is very special and basically needed for the
> implementation of tmac.trace only.  The current code relies on having
> `\' as the escape character.  Using .dei, you can implement tmac.trace
> even if there is no escape character at all.  I've implemented this
> already in my private groff version, and it works.

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

> > It would be even more programmatically useful to have a return
> > request so that:
> > 
> > .de test
> > .ie '\\$1'1' .return one
> > .el \{.ie '\\$1'2' .return two
> > .el .return three
> > .\}
> > ..
> > .de something
> > .ds page \\*[test] \\n%
> > ..

> I like this idea, but I think that it is rather hard to implement
> since groff doesn't `intern' the macros.  You can easily mimick this
> behaviour with a temporary register or string:

> .de test
> .  ds @temp
> .
> .  ie '\\$1'1' .ds @temp one
> .  el \{.ie '\\$1'2' .ds @temp two
> .  el .ds @temp three
> .  \}
> .
> .  nop address@hidden
> .  rm @temp
> ..

Yes, this is what I do already, except for the last two lines -- I use
@temp in whatever macro called .test and then remove @temp once it has
been used in that macro. Otherwise, I wouldn't know how to get the
value back. I was just hoping for a cleaner approach. Is the problem
with "interning" the macros related to the fact that my use of \\*[test]
in the above example doesn't work and is hard to implement in itself?
Does it have to do with how lines are parsed? For example, in:

.ds page \\*[test] \\n%

the test macro would need to be interpreted first, then \\n%
recognized as its argument, etc. In testing, I couldn't get \\*[test]
to be seen as a macro request, so I realize I don't understand in what
circumstances the fact that macros, strings, and requests share the
same namespace allows one to call a request or macro with the string
syntax (i.e., in the middle of an input line). The fact that one can
do this in TeX seems to me to be one of its few advantages over groff.
Besides the above example, 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>

It's easy to write scripts that read a table to convert tags to
troff requests so that troff sees it as:

This is a line of text.
.superscript_begin
1
.superscript_end

In fact, you don't even need to have a lookup table for this: every
tag can just be prepended with "." and suffixed with _begin or _end as
appropriate.
But then you need to deal with the whitespace you'll get before the 1.
In dealing with this I have the script always surround the text with
\& and \c:

\&This is a line of text.\c
.superscript_begin
\&1\c
.superscript_end

which makes the conversion script only marginally more complicated.
But I would prefer to use:

This is a line of text.\*[superscript_begin]1\*[superscript_end]

which will only work if I define the strings with other strings and
escape sequences, such as:

.ds superscript_begin \fR\s[(u;\\n[.s]z*2/3)]\u
.ds superscript_end \d\s0\fP

but, AFAIK, any other kind of request can't be used here. I could get
around the problem by adding more intelligence to the conversion
script so that it would handle some requests differently than others,
that is, some tags would be converted to strings and some to macros,
but that would mean changing the scripts from job to job or from DTD
to DTD, because at that point you need to have a lookup table for tag
conversion.

I would rather have general scripts for conversion to troff source
(scripts that can be used for all XML files, for example) and do the
customizing in the troff macros. I feel that the thing that changes
from job to job is the typesetting, so that's where the work should be
done. Having inline requests would facilitate this considerably.

But back to the .return request idea. Thinking about programming
again, another advantage to the .return is to cause a break in the
code at that point, which I think in many cases might speed up
processing. It might also get around the messiness in .el .ie
combinations that end up in heavily nested braces. We could have
something more like a case/switch statement instead:

.if '\\$1'1' .return one
.if '\\$1'2' .return two
.if '\\$1'3' .return three
.if '\\$1'4' .return four
.if '\\$1'5' .return five
.if '\\$1'6' .return six
.if '\\$1'7' .return seven

which is much neater than the equivalent .el \{.ie ...  sequence and, for
really long series of cases, I would assume it cuts down on
processing. The .break command doesn't work in an .if statement, but
that would help as well. Even the following would be an improvement:

.if '\\$1'1' \{\
.       ds @temp one
.       break
.\}
.if '\\$1'2' \{\
.       ds @temp two
.       break
.\}
.if '\\$1'3' \{\
.       ds @temp three
.       break
.\}
.if '\\$1'4' \{\
.       ds @temp four
.       break
.\}
.if '\\$1'5' \{\
.       ds @temp five
.       break
.\}
.if '\\$1'6' \{\
.       ds @temp six
.       break
.\}
.if '\\$1'7' \{\
.       ds @temp seven
.       break
.\}



> Is there a way to start a line with whitespace using the .tm request?

> groff has no possibility (currently) to do that which is not ideal.
> What about original troff?  What does the following produce?

> .tm \tHallo

> Any idea how to start a line with spaces?  I would like to implement
> that.  What syntax do you suggest?  Note that `\&' etc. is output
> literally (i.e., `\' followed by `&').

If you are going to add such a facility to .tm (a good idea, it seems
to me), I think it ought to be consistent with other requests. For
.ds, for example, a leading quotations character is stripped and the
following whitespace is preserved. Why not have the same thing for
.tm?

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