> 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.
