At 2025-02-22T01:31:28+0100, onf wrote: > On Sat Feb 22, 2025 at 12:12 AM CET, G. Branden Robinson wrote: > > At 2025-02-21T15:22:02+0100, onf wrote: > > [...] > > > Ideally, `so` would behave like `tm` except it would trim spaces > > > at the end, but I understand that this would be adding yet another > > > special case. > > > > Alternatively, we could make `tm` more consistent with `so` and > > numerous other requests (as they exist in groff Git's master > > branch). > > > > https://savannah.gnu.org/bugs/?66625 > > Personally, I don't like how all of this breaks backwards > compatibility
I wonder about it a bit myself, which is why the bug is "open" with
status "none". (It could just as well be "postponed", since once I've
detangled myself from the many ramifications of Savannah #66675, I think
it will be about time for a release candidate.)
But I think it makes sense to reason about backward compatibility in
concrete, not merely abstract terms.
How many people are putting double quotes at the beginnings of the
terminal messages they write with `tm` and `ab`? Because that's the
only change here. (And it's why GNU troff has `tm1`.)
Maybe some people have done so; if I follow through on Savannah #66625,
I mean to preserve traditional AT&T troff behavior of `tm` and `ab` in
compatibility mode, mainly because I can imagine people using `tm`, if
not `ab`, to write out indexing or bibliographic material in a format of
their choice. CSV format, which will surely start with a quotation mark
if the first field on the line has embedded spaces, is not the wildest
possibility, even if not deeply embedded in Unix text-file processing
tradition.
In compatibility mode, I remind the reader, one can still obtain GNU
troff behavior via the `do` request.
> (not to mention the already limited interoperability with Heirloom
> troff and neatroff).
When Heirloom Doctools troff was undergoing more active development,
this mailing list saw at least occasional participation from Carsten
Kunze, and he has a GNU Savannah account to this day. I think the best
way to manage interoperability concerns is to raise them on this list,
especially with planned changes, but I'm not sure that philosophy has
been shared by developers of non-GNU troffs. Mainly, people seem to
follow their own muses.
And that's fine, but I don't think it's fair to defend the prerogatives
of other troffs to innovate in whatever ways strike their developers as
expedient while at the same time insisting that GNU troff stand still,
vis à vis interoperability.
Combining your parenthetical with "all of this", I perceive a general
grievance with the direction of groff development.
If you mean some more narrowly focused form of critique, I would ask you
to be less vague.
> > > I never understood why the standard way of adding spaces to the
> > > end of a string is not following them with \&, e.g.
> > > .ds x Lorem \&
> > > .as x ipsum.
> >
> > The dummy character is a substantive thing; apart from its effect on
> > end-of-sentence detection, in GNU troff it contributes to the
> > measured length of a string.
>
> One could use \) to avoid end of sentence detection. (Yes, I know it's
> a groff invention.) The latter is trickier, but I wonder if anyone
> relies on `length` for anything other than `substring`?
In theory, they might, so we can never change it. Isn't that your
argument against Savannah #66625 and "all of this"?
> Because if not, `length` and `substring` could simply ignore \), too.
There's a nice, big, juicy can of worms implicated here. I can't find
the message right now, but I've written before (recently, even) about
just how ill-defined the interaction of "nodes" with string contents is.
Even `\)` is not a synonym for "nothing".[1] Observe.
$ printf '' | nroff -Z | grep . || echo NO OUTPUT
NO OUTPUT
$ printf '\\)' | nroff -Z | grep . || echo NO OUTPUT
x T utf8
x res 240 24 40
x init
p1
V40
H0
n40 0
x trailer
V2640
x stop
I can imagine a document author getting pretty frustrated if a string
seemed to interpolate nothing, its length measured zero, and yet upon
being interpolated, it caused a page to be output.
Regards,
Branden
[1] So what _is_ the damn thing? Well, in the forthcoming groff 1.24.0,
we at least have a means of coaxing it to identify itself.
$ printf '\\)\n.pline\n' | nroff -z
{type: line_start_node, diversion level: 0},
{type: transparent_dummy_node, diversion level: 0}
signature.asc
Description: PGP signature
