Follow-up Comment #5, bug #64202 (project groff):
[comment #4 comment #4:]
> [comment #3 comment #3:]
> > [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.
>
> ...and there are no cases of it doing so in the groff tree,
Seriously? Is your day job related to government, in some shape or form? You
certainly seem to exhibit the politician's proclivity to spew verbiage, with
little. or no, bearing on the issue at hand.
> $ git grep 'MR.*\\%' || echo NONE
> NONE
A badly designed experiment, testing a bogus hypothesis, might be viewed as
disingenuous obfuscation ... perhaps not so in this case, but rather a
misunderstanding of the issue? In reality, there _are_ 197 cases arising from
abuse of '.MR @g@...', and one further, from abuse of '.MR @PSPRINT@ ...'
$ hg grep '^\. *MR *@g@' | wc -l
197
$ hg grep '^\. *MR *@' | wc -l
198
$ hg grep '^\. *MR *@[^g]'
src/roff/groff/groff.1.man:.MR @PSPRINT@ 1 .
> [...irrelevant verbiage snipped...]
> The purpose is not being subverted.
I guess we'll just have to agree to disagree, on that conclusion.
> You said yourself that the "seat" of this behavior is Makefile rules for
generating .[157] from .man. It would be wrong to do so in
"makevarescape.sed", for instance, because '@g@' and friends get expanded in
contexts other than _roff_ sources. Moreover, valid _roff_ input is indeed
being produced.
>
> [...more verbiage snipped...]
> This is why I mentioned the following point in comment #1.
>
> > You do not _need_ to sanitize content destined for device control escape
sequences (or the `device` request) of the `\%` escape sequence. The
formatter will ignore this escape sequence in that context, skipping over it
without diagnostic, and it will not appear in the "x X" commands that GNU
troff produces. This is already the case in groff 1.22.4 and therefore I
suspect it's been true for many years.
Well, it _does_ propagate through pdfmark output to grops. Perhaps the
pdfmark macro _should_ sanitize its output, but that seems like a huge
overhead in tmac code ... every single byte of pdfmark throughput would need
to be inspected, just to weed out a miniscule few rogues.
> Are you wrapping or replacing the `MR` macro
Yes, and ...
> and "sanitizing" its first argument for some other purpose?
...no; it's a consequence of _not_ sanitizing the first argument, coupled with
your abuse of '@g@', (and maybe also of '@PSPRINT@'), in man page source, that
allows the unwanted '\%' to propagate.
> You said:
>
> > (which, in its present state of development, does not incur any address
sanitizer overhead)
>
> ...which I didn't completely understand, as ASAN doesn't seem relevant to
the present discussion of _roff_ macro processing.
>
> Leaving in "Need Info" status, as I'm stuck; I don't agree with your
implication that repeated leading \% escape sequences in a word are invalid
_roff_ input,
I neither said, nor even remotely implied, any such thing.
> and I don't have enough insight into the implementation you're working on to
offer advice. Maybe you could share some of its code.
I'll post it on OSDN, when I get it to a "commit-ready" state. I do have it
working, quite nicely, now, but with my MR macro override "uglified" by the
need to filter out '\%' prefixes, from its first argument.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?64202>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
