Hi Peter, I get the same output you do from your second example.
I do observe that `\a` in interpretation mode doesn't get warned about,
even with '-ww'. That may be a defect.
At 2023-09-02T16:19:08-0400, Peter Schaffter wrote:
> Question 1:
> Is \a only interpreted in copy mode as this would suggest?
Yes. This has been documented for a long time, but I don't think very
clearly. Until (he boasted) groff 1.23.0.
===snip===
5.12.1 Leaders
--------------
Sometimes it is desirable to fill a tab stop with a given glyph, but
also use tab stops normally on the same output line. An example is a
table of contents entry that uses dots to bridge the entry name with its
page number, which is itself aligned between tab stops. The 'roff'
language provides "leaders" for this purpose.(1) (*note
Leaders-Footnote-1::)
A leader character (ISO and EBCDIC code point 1, also known as SOH or
"start of heading"), behaves similarly to a tab character: it moves to
the next tab stop. The difference is that for this movement, the
default fill character is a period '.'.
-- Escape sequence: \a
Interpolate a leader in copy mode; see *note Copy Mode::.
===snip===
5.24.2 Copy Mode
----------------
When GNU 'troff' processes certain requests, most importantly those
which define or append to a macro or string, it does so in "copy mode":
it copies the characters of the definition into a dedicated storage
region, interpolating the escape sequences '\n', '\g', '\$', '\*', '\V',
and '\?' normally; interpreting '\<RET>' immediately; discarding
comments '\"' and '\#'; interpolating the current leader, escape, or tab
character with '\a', '\e', and '\t', respectively; and storing all other
escape sequences in an encoded form.
===snip===
My mental model is that tabs and leaders require an alternative form for
storage in macros (and strings) because when they're interpolated, the
tab stops may be different than when they were stored.
> Question 2:
> What is causing the erroneous justification of the third line?
> There's more than enough room for "air" and some leader.
There is not, in the example you provided. You set one tab stop, at the
line length (meaning at the right margin), so there was no hope of
"air"+leader fitting on the line.
> Question 3:
> Why do the leaders not respect .ta \n[.l]u?
As I understand your example, the leader respected your tab stop
precisely; it was of the correct length to reach the configured right
margin _relative to the horizontal drawing position corresponding to the
start of the input line_, was formatted, was too long, could not be
hyphenated, and so was kicked to the next line. Leaders, like tabs, are
not considered break points.
The underscored point is yet another devilish feature of AT&T troff. I
was thinking about this very matter the other morning; I think my
unconscious is slowly groping its way toward a description that
motivates this behavior. Something to do with the input getting filled
by default. GNU troff's `linetabs` feature seems to more closely meet
the expectations of people who didn't work at the Bell Labs CSRC in the
1970s.
===snip===
5.1.6 Tabs and Leaders
----------------------
GNU 'troff' translates input horizontal tab characters ("tabs") and
<Control+A> characters ("leaders") into movements to the next tab stop.
Tabs simply move to the next tab stop; leaders place enough periods to
fill the space. Tab stops are by default located every half inch
measured from the drawing position corresponding to the beginning of the
input line; see *note Page Geometry::. Tabs and leaders do not cause
breaks and therefore do not interrupt filling. Below, we use arrows ->
and bullets * to indicate input tabs and leaders, respectively.
1
-> 2 -> 3 * 4
-> * 5
=> 1 2 3.......4 ........5
===snip===
Please challenge my claims (and my writing!) so that we can clarify this
long-vexing issue in our manual. :)
Regards,
Branden
signature.asc
Description: PGP signature
