Follow-up Comment #19, bug #63581 (project groff): [comment #17 comment #17:] > I think there is a possible (3): When groff encounters an > infinite loop type situation it breaks the loop and returns an > error exit code to the user.
Groff will sometimes emit "fatal error: input stack limit exceeded (probable infinite loop)" (see, e.g., http://lists.gnu.org/r/groff/2022-11/msg00137.html). But it's also trivial to create an infinite loop that groff will never detect: echo '.while 1 .nr a 1' | groff And you're right that in the general case, the situation is not detectable. But you may be in luck: it looks like Deri has donned the RCA Man cape, and maybe the condition causing this lockup will turn out to be simple to fix. > In short yes - yes, that might work - mostly because that > particular option indicates when it hyphenates words (using a > <hy>) - the other options I'd seen that printed to the > terminal didn't - they just broke the word across lines. Yes, I've often found that aspect of -a output useful. But also, in the final analysis, any algorithmic count will be an approximation. A human reader can recognize "doctor-patient relationship" as three words but "pre-industrial civilization" as two, but try teaching an algorithm that distinction without bringing AI into it. Hyphens are sometimes word dividers and sometimes not. > I thought I had cracked it with '-Z -T utf8', but not so... Ah, earlier I missed that you were using -Z rather than the postprocessed output, so my trying to point the finger at grotty was misplaced. _______________________________________________________ Reply to this item at: <https://savannah.gnu.org/bugs/?63581> _______________________________________________ Message sent via Savannah https://savannah.gnu.org/
