Update of bug #66919 (group groff):
Status: Need Info => None
Assigned to: barx => None
_______________________________________________________
Follow-up Comment #18:
[comment #16 comment #16:]
> Follow-up Comment #14, bug #66919 (group groff):
>> But it seems that this mechanism to clear a code needs to carve
>> out an exception for what I'm terming "reflexive hcode," right?
>
> I think it has one.
Call me old-fashioned, but I prefer to go by how the code behaves rather than
by what it says. And the results of running the hcode_test in the [comment #0
original submission] tell us that "reflexive hcode" assigns a new, unique
hyphenation code (what it has always done) when the first parameter is
Latin-1, but not when the first parameter is a special character--even the
special character representing the same character that works in its Latin-1
form.
>> Because the purpose of [reflexive hcode] is to generate a new
>> hyphenation code for a character that may never have had one.
>
> ...or reset one to its virgin state after meddling.
Sorry, I'm not understanding how ".hcode x x" can ever reset a hyphenation
code. It can either do what it has always done, which is to generate a new,
unique hyphenation code; or it can "reset" the hyphenation code of character x
to... the value it already has.
> I am inclined to punt this question out into the Great
> Post-1.24 Hyphenation Reform Chinwag that Peter proposed.
OK, but punting the question implies restoring the .hcode behavior to its 1.23
state. That would be the more conservative approach, but it's overkill for
resolving this ticket, which is concerned only with the combination of
reflexive hcode, and the first character being a special character.
I'd change the Summary to specify this ticket is limited only to reflexive
hcode calls if that were an accepted term rather than one I invented in the
course of talking about this issue.
> The question I have for you right now is whether _groff_ master
> is working as you expect and desire specifically for Latin-1
> characters whose hyphenation codes we configure in "en.tmac",
Yes. I have no quarrel with this, and if I did, it would be out of scope for
this ticket.
> I also want to know whether spelling them as 8-bit ordinary
> characters or special characters works as you expect.
Ordinary characters, yes. Special characters, in reflexive context, no.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?66919>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
