Follow-up Comment #7, bug #66675 (group groff): At 2025-01-24T20:31:06-0500, Dave wrote: > Follow-up Comment #6, bug #66675 (group groff): > The problem is worse than originally reported as well,
Not happy to hear it, but glad you caught it.
Some status and commentary:
1. I've made progress on a rewrite of `define_character()` in
"src/roff/troff/input.cpp" that handles syntax correctly.
2. I plan to validate it my writing unit tests for character definition
and removal.
3. I can't (well, would strongly prefer not to) just revert the change
in question because it's part of the new "embed Unicode special
characters in device extension commands", meaning that I'd have to
revert a lot of other stuff as well. While I would be saddened to
rip out what I consider to be the flagship development in the GNU
troff formatter for the 1.24 cycle, a more practical reason for not
reverting is that, given the complexity of its landing, unwinding it
would I think be more difficult and error-prone than doing #1 and #2
together.
I've made a bet with myself that the reason the reading of special
character names from font description files is because once again, the
input token parser was drafted (inappropriately, design-wise) into
service for handling them.
Hmm, I just had a neat (and devilish, because I think it would
constitute strong evidence for my design opinion above) idea for testing
that hypothesis.
Will follow-up over the weekend, I hope.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?66675>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
