[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug #66040] [troff] no longer warns about unrecognized .hcode input
From: |
Dave |
Subject: |
[bug #66040] [troff] no longer warns about unrecognized .hcode input |
Date: |
Wed, 31 Jul 2024 14:45:55 -0400 (EDT) |
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
- [bug #66040] [troff] no longer warns about unrecognized .hcode input, (continued)
- [bug #66040] [troff] no longer warns about unrecognized .hcode input, G. Branden Robinson, 2024/07/29
- [bug #66040] [troff] no longer warns about unrecognized .hcode input, Dave, 2024/07/30
- [bug #66040] [troff] no longer warns about unrecognized .hcode input, G. Branden Robinson, 2024/07/30
- [bug #66040] [troff] no longer warns about unrecognized .hcode input, G. Branden Robinson, 2024/07/30
- [bug #66040] [troff] no longer warns about unrecognized .hcode input, Dave, 2024/07/30
- [bug #66040] [troff] no longer warns about unrecognized .hcode input, G. Branden Robinson, 2024/07/30
- [bug #66040] [troff] no longer warns about unrecognized .hcode input, G. Branden Robinson, 2024/07/30
- [bug #66040] [troff] no longer warns about unrecognized .hcode input, Dave, 2024/07/30
- [bug #66040] [troff] no longer warns about unrecognized .hcode input, G. Branden Robinson, 2024/07/31
- [bug #66040] [troff] no longer warns about unrecognized .hcode input, Dave, 2024/07/31
- [bug #66040] [troff] no longer warns about unrecognized .hcode input,
Dave <=