bug-groff
[Top][All Lists]
Advanced

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

[bug #64202] [man-pages]: groff_man(7) inconsistently (and redundantly)


From: Keith Marshall
Subject: [bug #64202] [man-pages]: groff_man(7) inconsistently (and redundantly) guards some .MR references with '\%'
Date: Wed, 17 May 2023 11:10:58 -0400 (EDT)

Follow-up Comment #3, bug #64202 (project groff):

[comment #1 comment #1:]
> Hi Keith,
> 
> I'm aware of this.  It's deliberate insofar as it's a consequence of other
decisions.
> 
> The main facts are these:
> 
> 1.  The new `MR` macro unconditionally prefixes its first argument with a
`\%` escape sequence to suppress hyphenation.

That's what I thought.  Consequently, there is _absolutely_ no need for
references, such as '.MR \%topic n', to _ever_ add that redundant '\%' prefix
to the topic name.

> 2.  All of _groff_'s man pages (.[157]) files are produced in the build tree
from from .man inputs.

Again, I'm well aware of this, but the '*.man' sources _do not_ specify the
redundant prefix, (other than incidentally, via a malformed transform for a
'@g@' prefix).

> 3.  The reason for that is that man page content is partially dynamic.  The
redundancy you're observing is the result of the "@g@" character sequence
being replaced by the ./configure-d command prefix in use by the build.  By
default, and in many build scenarios (of those I've seen personally, all
except for Solaris), this prefix is empty.

And, therein lies the bug ... for it _is_ a bug.  The intent of '@g@' is to
add a program name prefix -- typically 'g' for GNU programs -- so that 'tbl'
becomes 'gtbl', when appropriate; it has _absolutely no business_ to _ever_
include '\%' as part of that prefix.

(FWIW, the seat of the bug is within the substitution for '@g@', as it is
specified in the generated Makefile, at the point where 'topic.n' is generated
from 'topic.n.man').

> 4.  @g@ is expanded in several contexts, not just the first argument of
`MR`.  Wherever it occurs, it is part of a literal to which we do not want
automatic hyphenation to apply.

Understood.  However, the intent of '@g@' should _not_ be subverted, for this
unrelated purpose ... either specify '\%' _explicitly_, in any context where
it is intended, or introduce a specific transform, other than '@g@' itself,
which implies the effect of '\%@g@'.

> ...snip...
> 
> What do you think?

I think that this is an insidious bug, which should be fixed.


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?64202>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/




reply via email to

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