Update of bug #64439 (project groff):
Status: Need Info => None
Assigned to: barx => None
Summary: .chop does not treat a .char definition
atomically(?) => .chop cannot surmount the barrier of a .char definition
_______________________________________________________
Follow-up 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.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?64439>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
