Re: [groff] Heirloom: text disappearing when output line trap + interrupted text

[Tadziu Hoffmann]

> Based on this, if I understand correctly, without further knowledge
> whether some arbitrary text would be passed through a diversion or not, 
> one must make sure he escapes (e.g using "\&") all words starting
> with "."  or "'", such as below?
> AAA BBB BBB \&.CCC CCC

Yes.

(But beware of macros that internally change the control
characters -- you would have to escape the replacement
control characters, too. :-)

> Tadziu, would you know of any useful examples of using this feature?

I can't think of any.

For those cases where you explicitly do need to trigger a
macro when a diversion is replayed, the transparent line
embedding mechanism exists.

Otherwise, it's pretty unpredictable whether the text will
be formatted (say, in a filled paragraph) in such a way as
to make the macro request be at the beginning of a line,
because it would depend on the current font, font size,
line length, indent, hyphenation setting, space size, etc.
(unless you explicitly request a line break before).

Also, it doesn't happen when text is diverted with a nonzero
indent (probably because then the lines start with horizontal
motion instead of characters), which greatly reduces the
applicability of the feature.

(Which also suggests a fix of sorts: when formatting text
from input to output, simply precede every output line with a
special code such as \&, except those embedded transparently.)

> I am just curious what would be lost if the feature were to be considered 
> for removal; for example, to get a rough idea how often it is being used.

I guess nothing would be lost.  Groff doesn't have it, and as
far as I can tell it's never been missed.  (At least, no one
ever mentioned it as something useful to have... the very idea
seems so outlandish it probably never entered anyone's mind.)

I was actually surprised to see that this feature existed at
all in Heirloom and Unix nroff, and I would consider it to be
a bug (just not a bug that the Heirloom project introduced,
but one that was already present in Unix n/troff).

My guess is that it's not intentional, but just a result of
the routines that process input text, macros, and diversions
sharing common code (which I actually believe to be a good
thing for such a macro processing system).
And because words beginning with a leading dot are not very
common in normal text (which is why it was selected as control
character) most people probably never even noticed that this
feature was active.