Re: [Groff] problem with current snapshot

[Werner LEMBERG]

> > I'm not sure whether this classifies as a bug at all; it would
> > take some time to rewrite troff to handle that case gracefully
> > (and I haven't checked yet whether this is possible at all).
> > Opinions, please.  Gunnar, how does your troff behave?
> 
> It prints " 20 3" for
> 
> .do xflag 3
> .warn
> .nr x 20
> .nr y 3
> \s[\En[x]] \f[\En[y]] \n(.s \n(.f
> 
> with -a, so it seems to be able to handle this.

Thanks for checking.

> Looking at the groff code, it is not only \f which has this problem;
> it also affects \$ \* \F \g \k \m \M \O \V \Y, so \*[\E*[foo]] (or,
> more realistically, \E*[\E*[foo]]) does not work as well.

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


    Werner