[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [groff] Heirloom: text disappearing when output line trap + interrup
Re: [groff] Heirloom: text disappearing when output line trap + interrupted text
Thu, 25 Apr 2019 21:39:43 +0200
> 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
(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.