[bug #64439] .chop does not treat a .char definition atomically(?)

[Dave]

Follow-up Comment #2, bug #64439 (project groff):

Slightly reordering:

[comment #1 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




    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?64439>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/