Follow-up Comment #2, bug #67547 (group groff): At 2025-09-24T15:58:40-0400, Ingo Schwarze wrote: > Follow-up Comment #1: > > This ticket is completely pointless. > > Obviously, implementing the .Tg macro in groff(1) is utterly > impossible because groff has none of the prerequisite infrastructure > that would be required, and implementing the prerequisite > infrastructure would be extremely hard and arguably far outside the > scope of groff:
I don't agree with most of these claims. Here's _mandoc mdoc_(7)'s
description of the macro.
Tg [term]
Announce that the next input line starts a definition of the term.
This macro must appear alone on its own input line. The argument
defaults to the first argument of the first macro on the next line.
The argument may not contain whitespace characters, not even when it
is quoted. This macro is a mandoc(1) extension and is typically
ignored by other formatters.
When viewing terminal output with less(1), the interactive :t
command can be used to go to the definition of the term as described
for the MANPAGER variable in man(1); when producing HTML output, a
fragment identifier (id attribute) is generated, to be used for deep
linking to this place of the document.
In most cases, adding a Tg macro would be redundant because
mandoc(1) is able to automatically tag most definitions. This macro
is intended for cases where automatic tagging of a term is
unsatisfactory, for example if a definition is not tagged
automatically (false negative) or if places are tagged that do not
define the term (false positives). When there is at least one Tg
macro for a term, no other places are automatically marked as
definitions of that term.
So what `Tg` does is analogous to placing an "anchor" in HTML parlance.
Or, in PDF, placement of a "bookmark" to which "hotspots" can hyperlink.
Far from being "utterly impossible", groff's master branch has, since
the 1.23.0 release, actually implemented this for PDF.
Can this be done for other output formats? Yes. Obviously so for HTML.
For plain text, _groff_(1) and _man-db man(1_) could cooperate to
achieve what _mandoc man_(1) does; _man-db man_(1) could run _groff_(1)
in a mode that would generate one or more (c)tags files, and _man-db_
_man_(1) could pass that/those ctags files to _less_(1) as arguments to
its `-T` option. (I don't know if _less_(1) supports more than one, and
a multiplicity of tag files might not be a worthwhile scenario to
support.)
As I recall, the foregoing design, or something close to it, has already
been raised on the _groff_ mailing list, I think by Colin Watson.
I've pondered adding an argumentful `-A` option to GNU _troff_(1) anyway
to support specialized output formats that don't closely resemble fully
formatted/rendered text; the existing `-a` option selects one already,
but takes no option, hence the need for `-A` to take an argument to
select from a variety.
Thus, we could add (c)tags support to general *roff files.
> groff is a general-purpose typesetting system and not a manual page
> search & display system - in GNU-based systems, the latter function is
> typically filled by man-db, not by groff. Just as it is unreasonable
> to expect that mandoc can do everything that groff can do, it is
> unreasonable to assume that groff can do everything that mandoc can
> do. The reason why mandoc can usefully implement .Tg is because
> mandoc combines the relevant functionality of nroff -mdoc, the
> relevant functionality of nroff -man, all functionality of man-db, and
> additional functionality provided by none of these programs in one
> single, tightly integrated program.
As illustrated above, I don't perceive the gulf here that you do. The
foregoing solution would require cooperation between the groff and
man-db project, but these projects have a long history of avoiding
stepping on each other's toes, so I see no reason to be pessimistic
about its prospects.
> The macro name .Tg was chosen to not clash with anything in groff, and
> the semantics of the .Tg macro was specifically designed such that it
> can simply be ignored with no adverse effect by software that cannot
> implement it.
If _groff mdoc_ adds support for `Tg`, I think any proposal to use
_mandoc_(1)-incompatible semantics for it is likely a non-starter.
> When a user specifically ask for all warnings (-ww), it is completely
> reasonable to tell them that a manual page uses a macro that groff
> does not support, even if ignoring the macro does no harm and groff
> cannot reasonably implement it. The benefit of the warning for the
> user is that they are essentially told "if you use a different tool
> than groff for processing this manual page, you may or may not get
> additional functionality from this page that you won't get with
> groff."
I agree that the current behavior is predictable and reasonable given
_groff mdoc_'s utter lack of support for this macro name.
> Once again, just because a warning occurs does not mean that anything
> is broken and/or can be improved. Some warning just reflect reality
> and are there to stay, quite likely for good.
Regards,
Branden
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?67547>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
