[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Tadziu Hoffmann
Subject: Re: [groff] Heirloom: text disappearing when output line trap + interrupted text
Date: Thu, 25 Apr 2019 21:39:43 +0200
User-agent: Mutt/1.9.1 (2017-09-22)

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


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]