Follow-up Comment #14, bug #66040 (group groff): [comment #9 comment #9:] > > why would it be a bug that the special character is > > unrecognized only on its second appearance? > > If you mean "as the second member of a pair with itself", I > have an answer.
No, sorry for being unclear: I didn't mean its position in the .hcode list, I meant the thing in comment #5 that I said "should work" based on my reading of your new epic diagnostic. (My reading may not be correct, but I get the same reading from this new text added to the manual in [http://git.savannah.gnu.org/cgit/groff.git/commit/?id=4449a4f06 commit 4449a4f06]: "@var{src1} must be an ordinary character (other than a numeral) or a special character to which a hyphenation code has already been applied," so if I'm misunderstanding, I'm at least doing so consistently.) > So it's good that our documentation does the headstand. > We should not disclose what the hyphenation code values > are, we need only to ensure that they sort into the correct > equivalence classes, Hmm, I wonder if there's a better framework for presenting the whole concept to users. Such as (off-the-cuff brainstorming here), there are two things being stored about every character: * Is it valid for hyphenation consideration at all? This is a binary, yes/no question. * If the above is yes, what (if any) other hyphenation-equivalent characters does it map to? A user could imagine the binary value and the mapping something like: no @ yes A a Á á Ä ä yes B b yes C c Ç ç That there are "codes" at all ought to be irrelevant to the user's conceptual framework (other than that word lurking in the request name "hcode"). > The solution I proposed above would indeed fix bug #42870, > I think. Do you agree? It seems so to me. _______________________________________________________ Reply to this item at: <https://savannah.gnu.org/bugs/?66040> _______________________________________________ Message sent via Savannah https://savannah.gnu.org/
signature.asc
Description: PGP signature
