Update of bug #65962 (group groff):
Severity: 3 - Normal => 1 - Wish
Status: None => Postponed
_______________________________________________________
Follow-up Comment #1:
No defect is reported here; this is a wish list item. Setting severity.
> I have not seen the reasoning for this high value.
Consider that the only way to write a loop in A&T _troff_ was to write a
recursive macro.
An often better solution--and one that is more portable, since AT&T
'troff' lacked the 'while' request--is to instead write a recursive
macro. It will be parsed only once.(2) (*note while-Footnote-2::)
.de yy
. if (\\n(nm > 0) \{\
. \" many lines of code
. nr nm -1
. yy
. \}
..
.
.de xx
. nr nm 10
. yy
..
To prevent infinite loops, the default number of available
recursion levels is 1,000 or somewhat less.(3) (*note
while-Footnote-3::) You can disable this protective measure, or
raise the limit, by setting the 'slimit' register. *Note
Debugging::.
Next consider the sorts of things that one might loop over. A list of
references, say. In longer documents there could easily be more than 100 of
these. More than 1000? Less likely. (Though I do recall that my college
psychology textbook seemed to flirt with that order of magnitude.)
> I have run the build of groff with reduced values of the constant
"DEFAULT_INPUT_STACK_LIMIT"
> and it needs > 25 < 50 stack elements.
You could have just set the `slimit` register in the "tmac/troffrc", then
cleaned the build tree's "doc" directory and remade...
-- Register: \n[slimit]
If greater than 0, sets the maximum quantity of objects on GNU
'troff''s internal input stack. If less than or equal to 0, there
is no limit: recursion can continue until program memory is
exhausted. The default is 1,000.
Running experiments on short, dummy documents--or empty ones--is not going to
resemble the rendering of real documents.
I'm pleased to hear that you had difficulty getting _groff_ to grow the stack
beyond 50 "frames" just using its own facilities (macro packages, documents).
But that doesn't make 50 a reasonable limit for users' scenarios.
I'll postpone this ticket for now in case any further discussion occurs but my
intention at this point is to close it as rejected.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?65962>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
