bug-groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #66040] [troff] no longer warns about unrecognized .hcode input


From: G. Branden Robinson
Subject: [bug #66040] [troff] no longer warns about unrecognized .hcode input
Date: Tue, 30 Jul 2024 10:52:47 -0400 (EDT)

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/

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]