Update of bug #66919 (group groff):
Summary: [troff] .hcode no longer accepts a special character
as a first argument => [troff] .hcode sometimes fails to accept a special
character as a first argument
_______________________________________________________
Follow-up Comment #4:
[comment #3 comment #3:]
> We seem to be talking totally past each other.
It's our superpower!
> Right, I rapidly blundered into the same frustration.
Happily, after only 5 minutes of frustration I've managed to craft an input
file that shows the behavior change from older groffs (tested on 1.19.2,
1.22.4, and 1.23.0) to current groff. (Or current as of when this bug was
opened a couple days ago. I haven't built your latest push.) The following
has to be encoded via Latin-1 to accommodate .hcode's limitation on accepting
only an 8-bit character as its second argument.
.ll 1n
lanteronial
lanter\[~o]nial
.hcode \[~o] รต
lanter\[~o]nial
I recommend running the file with groff's "-a -Wbreak" options, though any
other output format should also suffice.
Here's the -a output I see in all listed older groffs:
<beginning of page>
lantero<hy>
nial
lanter<~o>nial
lanter<~o><hy>
nial
And here's current groff:
<beginning of page>
lantero<hy>
nial
lanter<~o>nial
lanter<~o>nial
The .hcode that formerly worked can be seen here to not work, based on the
different breaking behavior. And, notably, changing the first hcode parameter
from the special-character version to the Latin-1 version of the character
_does_ make this match older groff's behavior.
> The assertion in the bug summary is that ".hcode no longer accepts a
> special character as its first argument".
You're right, I failed to qualify the summary with a "sometimes" in light of
your modified example. Done now.
> How are we to distinguish special characters that are created with a
> default hyphenation code of zero from ones have that a hyphenation code
> of zero assigned to them by copying from an ordinary character that has
> a hyphenation code of zero?
But "reflexive hcode," if you will (that is, ".hcode x x," for any value of x)
is a special case that doesn't assign the hyphenation code of x to x, but
assigns a new, unique hyphenation code to x. (In some past bug report I
ruminated on the unwisdom of using the same syntax for "reflexive hcode" as
for other hcode assignments, but this is the syntax we've inherited.)
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?66919>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
