bugGNU roff - Bugs: bug #64439, [troff] .chop cannot surmount the...

 
 

bug #64439: [troff] .chop cannot surmount the barrier of a .char definition

Submitter:  Dave <barx>
Submitted:  Tue 18 Jul 2023 01:14:26 AM UTC
   
 
Category:  Core Severity:  3 - Normal
Item Group:  Incorrect behaviour Status:  None
Privacy:  Public Assigned to:  None
Open/Closed:  Open Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Sat 22 Jul 2023 10:01:17 AM UTC, comment #4: 

Adding one more iteration of the .chop/output sequence gives a result that's really inexplicable (to me, though maybe it'll actually be revealing to someone more familiar with the parser).  I get the same output in 1.22.4 and 1.23.

Dave <barx>
Group Member
Sat 22 Jul 2023 01:03:00 AM UTC, comment #3: 

Ah, I see.  Thanks, Dave.

Yes, it looks like the parser's idea of what it's working on and the `chop` request's are getting out of sync.  That's pretty bad.

If I tackle bug #62264, we'll have a string iterator, and maybe `chop` can be re-implemented as a macro.  I already have visions of a new `string.tmac` file we can ship, with (relatively) often-requested services like `index` and `rindex` for locating a character within a string.

I had been wondering about use cases for reversing the order of a string iterator, and this is a significant one.

G. Branden Robinson <gbranden>
Group administrator
Fri 21 Jul 2023 04:15:13 PM UTC, comment #2: 

Slightly reordering:

comment #1:

> ...it seems clear to be that `chop` (and other string-processing
> operations) should not be penetrating the boundary of the
> character definition, and correctly treat it as a
> character/glyph.


I agree that, as documented, this is what should happen.

> the defined-character object at the end of this string is
> being treated atomically--as an indivisible unit.


I took the presence of the warning to indicate that a partial chop of \[BS] is what was causing groff to think a newline was appearing inside an escape sequence.  So the root cause of the spurious warning seemed (to me) to be that .chop was not correctly treating it as an indivisible unit.

In fact, continuing to .chop away at the string seems to support this, because it never gets around to chopping any of the non-.char-defined content.

$ cat test2
.char \[BS] BELL LABS
.ds mystr ABC\[BS]
.nf
\[rs][BS] -> \[BS]
mystr -> \*[mystr]
.chop mystr
mystr -> \*[mystr]
.chop mystr
mystr -> \*[mystr]
.chop mystr
mystr -> \*[mystr]
.pl \n[nl]u
$ groff -Tascii test2
troff:test2:7: error: a newline character is not allowed in an escape sequence parameter
troff:test2:9: error: a newline character is not allowed in an escape sequence parameter
troff:test2:11: error: a newline character is not allowed in an escape sequence parameter
\[BS] -> BELL LABS
mystr -> ABCBELL LABS
mystr -> ABC
mystr -> ABC
mystr -> ABC


Dave <barx>
Group Member
Fri 21 Jul 2023 09:57:53 AM UTC, comment #1: 

Hmm, from what I understand of character definitions, this is working as expected, and the defined-character object at the end of this string is being treated atomically--as an indivisible unit.

Reviewing our Texinfo manual...


 -- Request: .char c [contents]
 -- Request: .fchar c [contents]
 -- Request: .fschar f c [contents]
 -- Request: .schar c [contents]
     Define a new character or glyph C to be CONTENTS, which can be
     empty.  More precisely, 'char' defines a 'groff' object (or
     redefines an existing one) that is accessed with the name C on
     input, and produces CONTENTS on output.  Every time glyph C needs
     to be printed, CONTENTS is processed in a temporary environment and
     the result is wrapped up into a single object.  Compatibility mode
     is turned off and the escape character is set to '\' while CONTENTS
     is processed.  Any emboldening, constant spacing, or track kerning
     is applied to this object rather than to individual glyphs in
     CONTENTS.

     An object defined by these requests can be used just like a normal
     glyph provided by the output device.  In particular, other
     characters can be translated to it with the 'tr' or 'trin'
     requests; it can be made the leader character with the 'lc'
     request; repeated patterns can be drawn with it using the '\l' and
     '\L' escape sequences; and words containing C can be hyphenated
     correctly if the 'hcode' request is used to give the object a
     hyphenation code.


...it seems clear to be that `chop` (and other string-processing operations) should not be penetrating the boundary of the character definition, and correctly treat it as a character/glyph.

What do you think?

(I continue to feel that the spurious diagnostic in #64101 is well observed, and should be fixed.)

G. Branden Robinson <gbranden>
Group administrator
Tue 18 Jul 2023 01:14:26 AM UTC, original submission:  

Reproducer airlifted in from bug #64101:

$ cat ATTIC/defchar.groff
.char \[BS] BELL LABS
.ds mystr ABC\[BS]
.nf
\[rs][BS] -> \[BS]
mystr -> \*[mystr]
.chop mystr
mystr -> \*[mystr]
.pl \n[nl]u
$ ./build/test-groff -Tascii ATTIC/defchar.groff
troff:ATTIC/defchar.groff:7: error: a newline character is not allowed in an escape sequence parameter
\[BS] -> BELL LABS
mystr -> ABCBELL LABS
mystr -> ABC

The less-than-illuminating diagnostic wording is #64101's subject.

Dave <barx>
Group Member

 

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

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    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.

     

    Follow 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2023-08-14 gbranden Summary.chop cannot surmount the barrier of a .char definition [troff] .chop cannot surmount the barrier of a .char definition
    2023-07-22 gbranden StatusNeed Info None
        Assigned tobarx None
        Summary.chop does not treat a .char definition atomically(?) .chop cannot surmount the barrier of a .char definition
    2023-07-21 gbranden StatusNone Need Info
        Assigned toNone barx
        Summary.chop does not treat a .char definition atomically .chop does not treat a .char definition atomically(?)

    Back to the top

    Powered by Savane 3.13-4b48.
    Corresponding source code