Follow-up Comment #17, bug #63581 (project groff):
[comment #13 comment #13:]
> You're right about the manpage. I doubt many read it. Still, it should
include mentioning the nroff "sort of incompatibility". As to sticking a .tm
into om.tmac, it won't help in the case of the OP's terminal freeze, but it is
the best solution. (Perhaps if he'd seen the warning in conjunction with
nroff-ed docs that worked, he wouldn't have been surprised to encounter a
problem.)
To answer the question, yes, it probably would have helped. I would have
likely figured out the problem wasn't with my code much quicker. I think it
is a good idea (in conjunction with the manpage change).
[comment #14 comment #14:]
> Yeah, the only ways to help the terminal freeze are (1) having mom reject
nroff as an output format entirely (which you point out is too extreme, even
if terminals are beyond mom's design parameters), or (2) someone volunteering
to root-cause the infinite loop and submit a patch.
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. That
would allow mom to display those documents it can in terminal, but avoid the
terminal freezing in cases where it can't. This might not be technically
feasible though - after all groff probably isn't going to realise it is going
to enter an infinite loop until it is in it, and when it is it won't be able
to get out of it (I think this is a type of Halting Problem?).
[comment #15 comment #15:]
> Gene, I wonder if one thing that might help you with what you're trying to
achieve is that, instead of using nroff output, you use groff output with the
"-a" option? This will still send output to the terminal, but it won't use
the nroff output driver (grotty), which seems to be one of the things
necessary to trigger this bug. "-a" output is not as attractive for human
readers, but if I'm understanding your use case correctly, users never see
groff's output; it's merely piped through another tool to get a word count.
Thank you for the suggestion. 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. If I count <hy> as minus a word, it should
all add up. I'll take a closer look at it - there appears to still be some
command words printed to terminal (i.e. "x X ps:exec [/Title (Sample mom
documents) /DOCINFO pdfmark"), but I might be able to filter them out.
Thanks. It is nowhere as near as neat as the '-Z -T utf8' option which
actually puts the words on their own line and makes for super easy counting;
but clearly that doesn't work for mom.
Just for background I did try some other things too. My first attempt was to
create a temporary ps file, then use ps2ascii to get the text, and then piped
that into wc to get the actual count. That was very messy, didn't actually
count words very well and included dependencies outside of groff and vim. I
then thought fine I'll just actually count words in vimscript and ensure I
don't count any groff commands. So this meant when someone types '.i
"""Master Control\|"""' I'd count two words and while '.sp 1.5i' then zero.
After a while of writing this in vimscript it occurred to me it was very
inefficient (nor would it cope well with future new macros with possibly
different rules) - I was basically writing a mini groff parsing engine in
vimscript; surely that would be better left to groff? I thought I had cracked
it with '-Z -T utf8', but not so...
Again thanks for your help.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?63581>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
