Follow-up Comment #6, bug #66040 (group groff):
[comment #5 comment #5:]
> [comment #4 comment #4:]
> > error("second member of hyphenation code pair must be an"
> > " ordinary character, or a special character already"
> > " assigned a hyphenation code");
>
> This message's problem isn't that it's long--it might be that it's not long
enough! Or at least not clear enough. I would read the second clause to mean
this should work.
> .hcode \['e] e
> .hcode \['E] \['e]
> But it doesn't. The special character \['e] in the second line is still
rejected even after being assigned a code in the first.
I noticed that too. I think it's a bug. I'm working on it.
> > Our documentation ("A hyphenation code must be an ordinary
> > character (not a special character escape sequence) other than
> > a digit or a space.") is wrong and I'll be fixing that, too.
>
> The digit exception is correct: "echo '.hcode a 8' | groff" emits the error
"hyphenation code cannot be digit" in 1.22.4, 1.23, and current code. The
space exception seems correct in the sense that there's not really a syntax
for indicating a space as an .hcode target: spaces are regarded as delimiting
the arguments, and escaping a space turns it into an escape sequence, no
longer a space.
The part I'm griefed about is "(not a special character escape sequence)".
A "hyphenation code" (an argument to the `hcode` request):
1. is always permitted as the destination (first of a pair), as in
.hcode \[S ,]s
from "tmac/ps.tmac".
2. _should_ be permitted as the source (second of a pair), *if* that code has
already been assigned a nonzero value.
> I can't comment aside from that, since I'm not sure what exception to the
special-character prohibition your proposed diagnostic is trying to convey.
Watch this space, so to speak.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?66040>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
