bugGNU roff - Bugs: bug #66040, [troff] no longer warns about...

 
 

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

Submitter:  Dave <barx>
Submitted:  Mon 29 Jul 2024 07:07:31 AM UTC
   
 
Category:  Core Severity:  2 - Minor
Item Group:  Warning/Suspicious behaviour Status:  None
Privacy:  Public Assigned to:  gbranden
Open/Closed:  Open Planned Release:  None
* Mandatory Fields

Post a Comment

Add a New Comment Rich Markup
   

Discussion

Jump to the original submission

Sun 16 Mar 2025 03:24:40 PM UTC, comment #21: 

comment #20:

> So this confirms that the ".hcode \[~o] \[~o]" does nothing, and
> also now fails to warn or error


To clarify: the above snippet doesn't on its own demonstrate the lack of diagnostics, since the fgrep filters stderr in a way that would remove any warning or error.  But it's easy to run it without the filter, or to run just the .hcode requests, to see the absence of diagnostics.

$ fgrep hcode 66040.pchar.test | groff-latest -ww
$


> The "does nothing" part is additionally distressing


and is now its own ticket, bug #66919.

Dave <barx>
Group Member
Thu 13 Mar 2025 06:19:04 PM UTC, comment #20: 

Whoops, the "66040.test" file of the last comment wasn't a fair test: ".hcode \[~o] \[~o]" and ".hcode \[~o] o" don't do equivalent things.  To be equivalent, the second one should be (in Latin-1 encoding) ".hcode \[~o] õ".  But making this change produces no change in the breaking of "mythõlõgy," so that test is inconclusive.

Maybe, instead of testing behaviors, I should just use the new tools available to peer directly into groff's mind.  February's .pchar request tells me what I want to know.

$ iconv -f iso-8859-1 66040.pchar.test
.pchar \[~o]
.hcode \[~o] \[~o]
.pchar \[~o]
.hcode \[~o] õ
.pchar \[~o]
.hcode \[~o] o
.pchar \[~o]
$ groff-latest -ww 66040.pchar.test 2>&1 | fgrep 'hyphenation code:'
  hyphenation code: 0
  hyphenation code: 0
  hyphenation code: 0
  hyphenation code: 111

So this confirms that the ".hcode \[~o] \[~o]" does nothing, and also now fails to warn or error (the problem originally reported for this ticket, fixed in August, and broken again at some point hence).

The Latin-1 input line ".hcode \[~o] õ" also does nothing and fails to report this.  (The "does nothing" part is additionally distressing because that used to work, but I need to look into whether this is an intentional change in how input encoding is handled.  The present ticket concerns only the "fails to report" aspect, and that's a valid concern even if "does nothing" is expected in this case.)

Dave <barx>
Group Member
Wed 12 Mar 2025 03:20:01 AM UTC, comment #19: 

Huh.  It seems this fix has been regressed at some point in the interim.

Using the hcode.groff input file from the commit log:

  • groff 1.22.4 and 1.23 produce diagnostics for lines 2, 3, 5, 6, 7, 12, and 14.  This is expected; the extra diagnostics for lines 1 and 4 were respectively added in the (post-1.23) commits cited in comment #2 and comment #17.
  • git HEAD produces diagnostics for lines 1, 2, 3, 4, 5, and 7.  So 1 and 4 were added--but 6, 12, and 14 were subtracted.


First thought: the subtractions may be the result of the since-committed fix for bug #66112.  Since tmac/en.tmac now sets up hcode values for \['A], \['o], and \['U], perhaps the need for those error messages has disappeared.

Nope.  Using a character not defined in en.tmac produces the same results.

$ echo '.hcode \[~o] \[~o]' | groff
troff:<standard input>:1: error: hyphenation code must be ordinary character
$ echo '.hcode \[~o] \[~o]' | groff-latest -ww
$ groff-latest --version | head -1
GNU groff version 1.23.0.2755-d1992-dirty

Could this mean that, instead of the diagnostic being regressed, that bug #42870 was accidentally fixed sometime?

Sadly, also nope.

$ cat 66040.test
.ll 1n
.hcode \[~o] \[~o]
mythology
myth\[~o]l\[~o]gy
.hcode \[~o] o
mythology
myth\[~o]l\[~o]gy
$ groff-latest -a -Wbreak 66040.test
<beginning of page>
mythol<hy>
ogy
myth<~o>l<~o>gy
mythol<hy>
ogy
myth<~o>l<hy>
<~o>gy

So ".hcode \[~o] \[~o]" is still invalid input, but no longer (again) produces a diagnostic.

Dave <barx>
Group Member
Wed 12 Mar 2025 01:51:21 AM UTC, comment #18: 

Clerical note: The commit IDs in comment #15 and comment #17 both appear to be preliminary ones.  The one that was pushed ended up being fc727f4435e1ab290870ee7951132a66bb148b5d.

Dave <barx>
Group Member
Sun 04 Aug 2024 09:06:54 PM UTC, comment #17: 

Pushed.


commit f4435e1ab290870ee7951132a66bb148b5d
Author: G. Branden Robinson <g.branden.robinson@gmail.com>
Date:   Thu Aug 1 16:45:35 2024 -0500

    [troff]: Validate `hcode` request arguments more.

    * src/roff/troff/input.cpp (set_hyphenation_code): Do more input
      validation of `hcode` request arguments.  Handle case where an
      argument is an escape sequence (but not a special character) ourselves
      instead of delegating it to `token::get_char()`.  Throw errors (and
      stop processing arguments) when (1) the destination character is a
      numeral; (2) the destination character is a (non-special-character)
      escape sequence; (3) the source character is a numeral; or (4) the
      source character is a (non-special-character) escape sequence.

    * doc/groff.texi.in (Manipulating Hyphenation) <hcode>:
    * man/groff_diff.7.man (New requests) <hcode>: Document that the request
      aborts processing its arguments upon encountering an invalid one.

    Continues <https://savannah.gnu.org/bugs/?66040>.  Thanks to Dave Kemper
    for further discussion.

    $ nl hcode.groff
         1  .hcode
         2  .hcode \:
         3  .hcode a
         4  .hcode 0 b
         5  .hcode c\:
         6  .hcode \['A] \['a]
         7  .hcode d 0
         8  .hcode eE
         9  .hcode f F
        10  .hcode g G\" This is my comment.
        11  .hcode \['i] i
        12  .hcode \['o] \['o]
        13  .hcode \['u] u
        14  .hcode \['U] \['u]
    $ ./build/test-groff -T utf8 -ww hcode.groff
    troff:hcode.groff:1: warning: hyphenation code configuration request expects arguments
    troff:hcode.groff:2: error: expected ordinary or special character, got an escaped ':'
    troff:hcode.groff:3: error: hyphenation codes must be specified in pairs
    troff:hcode.groff:4: error: cannot apply a hyphenation code to a numeral
    troff:hcode.groff:5: error: expected ordinary or special character, got an escaped ':'
    troff:hcode.groff:6: error: second member of hyphenation code pair must be an ordinary character
    troff:hcode.groff:7: error: cannot use the hyphenation code of a numeral
    troff:hcode.groff:12: error: second member of hyphenation code pair must be an ordinary character
    troff:hcode.groff:14: error: second member of hyphenation code pair must be an ordinary character


G. Branden Robinson <gbranden>
Group administrator
Thu 01 Aug 2024 10:17:02 PM UTC, comment #16: 
G. Branden Robinson <gbranden>
Group administrator
Thu 01 Aug 2024 09:48:41 PM UTC, comment #15: 

I've got some new stuff on the cooker.


commit bc4036b10995058cce7a96949ca13ca2dcb96496 (HEAD)
Author: G. Branden Robinson <g.branden.robinson@gmail.com>
Date:   Thu Aug 1 16:45:35 2024 -0500

    [troff]: Validate `hcode` request arguments more.

    * src/roff/troff/input.cpp (set_hyphenation_code): Do more input
      validation of `hcode` request arguments.  Handle case where an
      argument is an escape sequence (but not a special character) ourselves
      instead of delegating it to `token::get_char()`.  Throw errors when
      (1) the destination character is a numeral; (2) the destination
      character is a (non-special-character) escape sequence; (3) the source
      character is a numeral; and (4) the source character is a
      (non-special-character) escape sequence.  Improve wording of existing
      diagnostic, noting validity of special character escape sequence as a
      source character _if_ it has already been assigned a hyphenation code
      (implicitly: a non-zero one).

    * doc/groff.texi.in (Manipulating Hyphenation) <hcode>:
    * man/groff_diff.7.man (New requests) <hcode>: Document that the request
      aborts processing its arguments upon encountering an invalid one.

    Continues <https://savannah.gnu.org/bugs/?66040>.  Thanks to Dave Kemper
    for further discussion.

    $ nl hcode.groff
         1  .hcode
         2  .hcode \:
         3  .hcode a
         4  .hcode 0 b
         5  .hcode c\:
         6  .hcode \['A] \['a]
         7  .hcode d 0
         8  .hcode eE
         9  .hcode f F
        10  .hcode g G\" This is my comment.
        11  .hcode \['i] i
        12  .hcode \['o] \['o]
        13  .hcode \['u] u
        14  .hcode \['U] \['u]

    $ ./build/test-groff -T utf8 -ww hcode.groff
    troff:hcode.groff:1: warning: hyphenation code configuration request expects arguments
    troff:hcode.groff:2: error: expected ordinary or special character, got an escaped ':'
    troff:hcode.groff:3: error: hyphenation codes must be specified in pairs
    troff:hcode.groff:4: error: cannot apply a hyphenation code to a numeral
    troff:hcode.groff:5: error: expected ordinary or special character, got an escaped ':'
    troff:hcode.groff:6: error: second member of hyphenation code pair must be an ordinary character, or a special character already assigned a hyphenation code
    troff:hcode.groff:7: error: cannot use the hyphenation code of a numeral
    troff:hcode.groff:12: error: second member of hyphenation code pair must be an ordinary character, or a special character already assigned a hyphenation code


G. Branden Robinson <gbranden>
Group administrator
Wed 31 Jul 2024 06:45:52 PM UTC, comment #14: 

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 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.

Dave <barx>
Group Member
Wed 31 Jul 2024 08:44:58 AM UTC, comment #13: 

comment #6:

> 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".


Ah, but the documentation does say that; you just have to look at the context:

-- Request: .hcode c1 code1 [c2 code2] ...
    Set the hyphenation code of character C1 to CODE1, that of C2 to
    CODE2, and so on.  A hyphenation code must be an ordinary character
    (not a special character escape sequence)

Here, the odd-numbered arguments are "characters" and the even-numbered ones "codes."  It may not be written as clearly as it could be, but it is accurate to how the arguments are defined: the "not a special character" parenthetical applies only to codes, the even-numbered arguments.

I do note that one thing missing from the description is that the spaces between arguments are optional, which the ps.tmac example demonstrates.

Dave <barx>
Group Member
Wed 31 Jul 2024 06:42:47 AM UTC, comment #12: 


commit c34502070b1374cceec484b0b825f80ab8d812bf
Author: G. Branden Robinson <g.branden.robinson@gmail.com>
Date:   Mon Jul 29 23:11:11 2024 -0500

    [troff]: Fix Savannah #66040 (`hcode` & `\[xxx]`).

    * src/roff/troff/input.cpp (set_hyphenation_code): Restore diagnostic
      message when attempting to assigning the hyphenation code of a special
      character to another character (special or ordinary).  Also initialize
      local variable much closer to where we test its value, for
      readability.

    Fixes <https://savannah.gnu.org/bugs/?66040>.  Thanks to Dave Kemper for
    the report.


G. Branden Robinson <gbranden>
Group administrator
Wed 31 Jul 2024 03:28:42 AM UTC, comment #11: 

Fuller reply later, when I've had time to digest all this, but to get the ball rolling:

comment #10:

> What I gather is that what bug #42870, and you, are asking for
> is that we be able to substitute special characters for these
> ordinary ones.


Correct.  (Or, to be more specific, able to substitute special characters for the second character of each pair; .hcode has long accepted them for first of each pair.)

> I think the only reason it hasn't been done is because there
> was no good answer for "what character code does a special
> character have"?


I figured there had to be some complication under the hood, because the UI change seems so trivial that Werner would have knocked it out in an hour a decade or two ago.

Dave <barx>
Group Member
Wed 31 Jul 2024 12:13:39 AM UTC, comment #10: 

I said:

> Accented vowels are members of those equivalence classes in GNU troff


That's actually not true.

In German, they're all _sui generis_ except for the uppercase versions.


.hcode ä ä  â â  à à  á á  ã ã  å å  æ æ
.hcode ç ç
.hcode é é  è è  ë ë  ê ê
.hcode í í  ì ì  î î  ï ï
.hcode ñ ñ
.hcode ó ó  ò ò  ô ô  ö ö  ø ø
.hcode ú ú  ü ü  û û
.
.hcode Ä ä  Â â  À à  Á á  Ã ã  Å å  Æ æ
.hcode Ç ç
.hcode É é  È è  Ë ë  Ê ê
.hcode Í í  Ì ì  Î î  Ï ï
.hcode Ñ ñ
.hcode Ó ó  Ò ò  Ô ô  Ö ö  Ø ø
.hcode Ú ú  Ü ü  Û û
.
.hcode ß ß


What I gather is that what bug #42870, and you, are asking for is that we be able to substitute special characters for these ordinary ones.

And if that is the case I agree.  I think the only reason it hasn't been done is because there was no good answer for "what character code does a special character have"?

My answer, which one may claim is not a very good one, is that we can make one up--one that is larger than 255 so there is no chance of collision in GNU troff's currently limited mind.

The same technique can be retained in a UTF-8 GNU troff; Unicode is a 20.1-bit encoding in a 32-bit space.  We'll have some room.  And even if the set of predefined special characters is completely handled by existing defined Unicode code points (spoiler alert: it isn't, but just barely), users can create new special characters with the `char` request so we'll still need the flexibility anyway.

I mean, assuming any groff user would ever write custom hyphenation pattern files for their constructed language.

Proper hyphenation of Sindarin, coming in groff 1.25!

G. Branden Robinson <gbranden>
Group administrator
Wed 31 Jul 2024 12:05:13 AM UTC, comment #9: 

comment #8:

> comment #6:
> > comment #5:
> > > 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.
>
> I mean, sure, that could be called a bug... but 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.

Because the formatter doesn't know what value to give it.  Under the hood, it's just a character code--in other words, on an ISO 8859 system, the hyphenation codes for 'a' through 'z' are 97 through 122--but our documentation stands on its head to avoid saying that.  The trouble is that there is a potentially larger space of sui generis special characters, by which I mean ones that don't belong to an equivalence class of a Basic Latin letter.  Accented vowels are members of those equivalence classes in GNU troff but the German Eszett is not.  If we had an Icelandic locale, thorn and eth would similarly have to have hyphenation codes above 127 decimal.

The real fun comes when you add letters from multiple ISO 8859 character sets.  Before long you're going to have collisions.

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, so that they then interoperate as desired with the hyphenation patterns.

When we get support for UTF-8-encoded hyphenation pattern files, things will become straightforward again.

In the meantime, what I think I will do is use a `static int` to mint a sequence number (starting at 256) for hyphenation codes any time a special character needs one sui generis.
 

> Why shouldn't it just be recognized in any .hcode invocation?


See above.

> And as it happens, that suggestion (bug #42870) was filed ten years ago--and its fixing would make .hcode's behavior simple to use and simple to document, whereas allowing it only in some cases complicates both of those.


The solution I proposed above would indeed fix bug #42870, I think.  Do you agree?

If so, we probably ought to copy the meat of it over to that ticket and mark it "in progress".
 

> > The part I'm griefed about is "(not a special character escape sequence)".
>
> It's griefworthy but it's not inaccurate.


It is.  A special character is sometimes okay, and has been for a long time, as I tried to illustrate in comment #6.

But it would be laborious and perhaps embarrassing to explain the cases where it isn't.

> Overturning it is #42870's life goal.


Yes--if my plan survives contact with the enemy, the parenthetical can die.

G. Branden Robinson <gbranden>
Group administrator
Tue 30 Jul 2024 06:43:11 PM UTC, comment #8: 

comment #6:

> comment #5:
> > 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.


I mean, sure, that could be called a bug... but why would it be a bug that the special character is unrecognized only on its second appearance?  Why shouldn't it just be recognized in any .hcode invocation?  And as it happens, that suggestion (bug #42870) was filed ten years ago--and its fixing would make .hcode's behavior simple to use and simple to document, whereas allowing it only in some cases complicates both of those.

> The part I'm griefed about is "(not a special character escape sequence)".


It's griefworthy but it's not inaccurate.  Overturning it is #42870's life goal.

Dave <barx>
Group Member
Tue 30 Jul 2024 03:01:34 PM UTC, comment #7: 

On second thought, it feels more orthogonal to go ahead and copy an uninitialized (zero) value from the second member of a hyphenation code pair.

And that would also solve the "problem" noted in a "TODO" commend of permitting the removal of a value from a hyphenation code.

(Though that's already possible, I think, with requests like `hcode a $` or `hcode \['e] #`.)

(Also this stuff is too friggin' hard to introspect.  I feel myself itching to write a `phcode` request to dump these things.)

G. Branden Robinson <gbranden>
Group administrator
Tue 30 Jul 2024 02:52:45 PM UTC, comment #6: 


comment #5:

> 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.

G. Branden Robinson <gbranden>
Group administrator
Tue 30 Jul 2024 02:38:31 PM UTC, comment #5: 

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.

> 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.

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.

Dave <barx>
Group Member
Tue 30 Jul 2024 03:47:01 AM UTC, comment #4: 

I have a fix.


diff --git a/src/roff/troff/input.cpp b/src/roff/troff/input.cpp
index d0ef4a0f1..11d58e05b 100644
--- a/src/roff/troff/input.cpp
+++ b/src/roff/troff/input.cpp
@@ -7291,15 +7291,22 @@ static void set_hyphenation_codes()
       break;
     tok.next();
     tok.skip();
-    unsigned char c = tok.ch();
     if (tok.is_newline() || tok.is_eof()) {
       error("hyphenation codes must be specified in pairs");
       break;
     }
     charinfo *ci2 = tok.get_char(true /* required */);
-    // nonsense redux
-    if (0 /* nullptr */ == ci2)
-      break;
+    unsigned char c = tok.ch();
+    if (0 == c) {
+      if (0 /* nullptr */ == ci2)
+       break;
+      if (0 == ci2->get_hyphenation_code()) {
+       error("second member of hyphenation code pair must be an"
+             " ordinary character, or a special character already"
+             " assigned a hyphenation code");
+       break;
+      }
+    }
     // TODO: What if you want to unset a hyphenation code?  Accept 0?
     if (csdigit(c)) {
       error("hyphenation code cannot be digit");


Longest diagnostic message EVAR, I know.  Sorry not sorry?

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.

G. Branden Robinson <gbranden>
Group administrator
Mon 29 Jul 2024 08:00:32 AM UTC, comment #3: 

comment #2:

> Some "improvement"!  :-O


I'm sure that commit made many improvements.  Sometimes taking three steps forward also involves taking one back.

Dave <barx>
Group Member
Mon 29 Jul 2024 07:24:31 AM UTC, comment #2: 

Some "improvement"!  :-O


0f49e6b5ee1ec575ed42e55be388009a16320516 is the first bad commit
commit 0f49e6b5ee1ec575ed42e55be388009a16320516
Author: G. Branden Robinson <g.branden.robinson@gmail.com>
Date:   Wed Nov 29 14:20:22 2023 -0600

    [troff]: Improve `hcode` request validation.

    * src/roff/troff/input.cpp (set_hyphenation_codes): Throw warning
      diagnostic if no arguments supplied.  Throw error diagnostic if there
      are an odd number of arguments.  Check second arguments of pairs for
      nonsense.

    Also:
    * Annotate null pointers with `nullptr` comment to ease any future
      transition to C++11, which defines it as a keyword.
    * Reorder comparison to avoid inadvertent lvalue assignment.

    Input:
    $ nl hcode.groff
         1  .hcode
         2  .hcode \:
         3  .hcode a
         4  .hcode a\:
         5  .hcode aA

    Before:
    $ groff -ww hcode.groff
    troff:hcode.groff:2: error: expected ordinary or special character, got an escaped ':'
    troff:hcode.groff:3: error: hyphenation code must be ordinary character
    troff:hcode.groff:4: error: hyphenation code must be ordinary character

    After:
    $ ./build/test-groff -ww hcode.groff
    troff:hcode.groff:1: warning: hyphenation code configuration request expects arguments
    troff:hcode.groff:2: error: expected ordinary or special character, got an escaped ':'
    troff:hcode.groff:3: error: hyphenation codes must be specified in pairs
    troff:hcode.groff:4: error: expected ordinary or special character, got an escaped ':'

 ChangeLog                |  9 +++++++++
 src/roff/troff/input.cpp | 19 ++++++++++++++++---
 2 files changed, 25 insertions(+), 3 deletions(-)


G. Branden Robinson <gbranden>
Group administrator
Mon 29 Jul 2024 07:19:25 AM UTC, comment #1: 

Goodness.  It's against my ethos to kill off a valid diagnostic message.  ;-)

G. Branden Robinson <gbranden>
Group administrator
Mon 29 Jul 2024 07:07:31 AM UTC, original submission:  

The Texinfo manual states about .hcode, "A hyphenation code must be an ordinary character (not a special character escape sequence) other than a digit or a space."  Thus the following warning, as emitted by groff 1.23.0:

$ echo ".hcode \['e] \['e]" | groff -ww
troff:<standard input>:1: error: hyphenation code must be ordinary character

But this warning has disappeared in a groff built from recent (circa two weeks ago) git code:

$ groff --version | head -1
GNU groff version 1.23.0.1528-d5d4-dirty
$ echo ".hcode \['e] \['e]" | groff -ww
$

Does this mean that the manual is out of date--that bug #42870 has been fixed and .hcode now recognizes special character escape sequences as hyphenation codes?

Sadly, no.  As the test file below shows, the .hcode request still fails to process the \['e] escape as a hyphenation code; groff simply no longer notifies the user of this.

$ file resume
resume: troff or preprocessor input, ISO-8859 text
$ iconv -f iso-8859-1 resume
.ll 1n
r\['e]sum\['e]
.hcode \['e] \['e]
r\['e]sum\['e]
.hcode \['e] é
r\['e]sum\['e]
$ groff -a -ww -Wbreak resume
<beginning of page>
r<'e>sum<'e>
r<'e>sum<'e>
r<'e><hy>
sum<'e>


Dave <barx>
Group Member

 

Attached Files

This item currently has no attached files.

(Note: upload size limit is set to 4.0MiB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

 

Dependencies

This item does not depend on any other items.

No items depend on this one.

 

Mail Notification Carbon-Copy List

Carbon-Copy List
  • -email is unavailable- added by gbranden (Posted a comment)
  • -email is unavailable- added by barx (Submitted the item)
  •  

    Votes

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

    History

    Follow 12 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2025-03-12 barx StatusFixed None
        Open/ClosedClosed Open
        Planned Release1.24.0 None
    2024-08-01 gbranden DependenciesRemoved dependency from bugs #42870 -
    2024-08-01 gbranden Dependencies- bugs #42870 is dependent
    2024-07-31 gbranden StatusIn Progress Fixed
        Open/ClosedOpen Closed
        Planned ReleaseNone 1.24.0
    2024-07-30 gbranden StatusConfirmed In Progress
    2024-07-29 gbranden StatusNone Confirmed
        Assigned toNone gbranden
    2024-07-29 gbranden Summarygroff no longer warns about unrecognized .hcode input [troff] no longer warns about unrecognized .hcode input

    Back to the top

    Powered by Savane 3.16-a7ba.
    Corresponding source code