Re: [Groff] problem with current snapshot

[Gunnar Ritter]

Werner LEMBERG <address@hidden> wrote:

> I know.  However, in cstr54.ps, p. 7, there's the following sentence:
>
>   The escape sequences \\, \., \", \$, \*, \a, \n, \t, \g, and
>   \<newline> are interpreted in copy mode (§7.2)
>
> I suppose this affects the results returned by those escape sequences?
>
> Regarding possible solutions, I wonder whether it makes sense to
> introduce, similar to \s, the notation \X'...' in addition to \X[...]
> (`\X' one of the affected escape sequences).

You actually mean \Y, I suppose?

> The current code handles
> the data within the brackets in copy mode (\s is an exception to
> this); using '...' delimiters I could add some code which allows \E.

Maybe the real issue is that AT&T troff and its derivatives
do not change to copy mode when reading names:

.ds xx foo
.ds \\f bar
\*(\f2xx \n(.f

prints "foo 2" with both 7th Edition troff and Heirloom troff.
With groff, it prints "bar2xx 1". Consequently, Heirloom troff
also does not change its mode when reading the contents of a
"\[...]" bracket sequence. And thus, both occurences of "\E"
in "\E*[\E*[foo]]" are interpreted as escape characters.

> Reason for such an extension would be velocity.  Copy mode is much
> faster than using the main processing loop (via the token::next()
> function).

In AT&T troff derivatives, it probably does not matter much;
the next character is (almost) always read using the "getch()"
function, and there is a global variable "copyf" that simply
disables some of the escape sequences in it if set to a value
other than zero.

        Gunnar