Follow-up Comment #3, bug #66919 (group groff): Hi Dave,
We seem to be talking totally past each other.
At 2025-03-17T22:12:04-0400, Dave wrote:
> 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.
Right, I rapidly blundered into the same frustration.
>> 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.
The assertion in the bug summary is that ".hcode no longer accepts a
special character as its first argument".
I believe that acceptance of a special charcter as the first `hcode`
request argument precisely what my input file illustrates. The
hyphenation code of the "source" (second argument, a lowercase letter
'a' with acute accent) is extracted and assigned to the special
character `\[~o]`.
> It doesn't change the erroneous behavior of my test.
How is your input file behaving erroneously?
>> ...and therefore its hyphenation code is 0, the default.
>
> Yes, which is my intent.
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?
If we can't, then short of a GDB session, I don't see how you can
sustain that claim. For what it's worth, I did actually run GDB on the
"troff" in Git HEAD and the control flow is correct. `\[~o]` _is_
recognized as a special character.
I could assign it a hyphenation code from a basic Latin letter instead.
That's no trouble.
$ printf '.pchar \\[~o]\n.hcode \\[~o] z\n.pchar \\[~o]\n' |
./build/test-groff 2>&1 | grep hyph
hyphenation code: 0
hyphenation code: 122
> I suspect your alternative input using a character that _is_ given a
> hyphenation code in latin1.tmac accounts for the difference in
> behavior.
My claim is that the fact that the assignment "took" and got applied to
the special character `\[~o]` is evidence that ".hcode no longer accepts
a special character as a first argument" is not a factual statement.
>> 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.
We're unlikely to run out of those.
$ echo '.pchar =' | ./build/test-groff
character '='
is not translated
does not have a macro
special translation: 0
hyphenation code: 0
flags: 0
ASCII code: 61
asciify code: 0
is found
is transparently translatable
is not translatable as input
mode: normal
>> 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.
I guess I don't understand where your siting the claim of the buggy
behavior. (Deri had a great expression for this, but I can't remember
it right now.)
I reiterate:
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?
Here's another demonstrator. Let's take a special character that starts
life (after startup files are read, importantly) with a nonzero
hyphenation code and see if we can get the `hcode` request to fail to
assign it a new one, illustrating your claim that ".hcode no longer
accepts a special character as a first argument".
$ printf '.pchar \\[`a]\n.hcode \\[`a] z\n.pchar \\[`a]\n' |
./build/test-groff 2>&1 | grep hyph
hyphenation code: 97
hyphenation code: 122
In what sense is the `hcode` request not working?
My working copy does tend to race ahead of Savannah, so I checked out
master and confirmed the foregoing exhibits using this commit.
commit 6469e004b219f35786e02d886d56808bba846cee (HEAD, origin/master,
origin/HEAD)
Author: G. Branden Robinson <g.branden.robin...@gmail.com>
Date: Sun Mar 16 09:35:30 2025 -0500
[troff]: Fix logic error.
Here's another illustrator.
$ printf '.ll 1n\n.pchar \\[`a]\n.hcode \\[`a] z\n.pchar \\[`a]\nfizzle
fi\\[`a]zle\n' | ./build/test-groff -Wbreak -a 2>&1
special character "`a"
is not translated
does not have a macro
special translation: 0
hyphenation code: 97
flags: 0
ASCII code: 0
asciify code: 224
is found
is transparently translatable
is translatable as input
mode: normal
special character "`a"
is not translated
does not have a macro
special translation: 0
hyphenation code: 122
flags: 0
ASCII code: 0
asciify code: 224
is found
is transparently translatable
is translatable as input
mode: normal
<beginning of page>
fiz<hy>
zle
fi<`a><hy>
zle
As I predicted, with this input, the \[`a] special character is
participating in hyphenation as the basic Latin letter `z` does.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?66919>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
