Follow-up Comment #2, bug #66919 (group groff): [comment #1 comment #1:] > I don't think you diagnosed this problem correctly.
Admittedly, it's hard to show the behavior change between git HEAD and any
previous version of groff, because no version before about a month ago had a
.pchar request. So I need to either backport .pchar into an older groff, or
craft a test that shows an observable output change.
> I have alternative facts. Er, I mean, an alternative input file.
OK, but this at best shows that the bug only occurs sometimes, not all the
time. It doesn't change the erroneous behavior of my test.
> ...and therefore its hyphenation code is 0, the default.
Yes, which is my intent. I suspect your alternative input using a character
that _is_ given a hyphenation code in latin1.tmac accounts for the difference
in behavior.
> There are multiple opinions about ...
I'm happy to kick that can down the road; for now, having a character that has
no hyphenation code defined in any startup file is useful for demonstrating
the bug.
> I propose that there is no bug here, or at a minimum, that GNU
> _troff_ is in fact accepting a special character as the first
> argument to the `hcode` request. What do you think?
I'm not clear on how "I can craft different input where .hcode does work"
invalidates the bug demonstrated by my input where it doesn't.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?66919>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
