https://bugs.documentfoundation.org/show_bug.cgi?id=105628
--- Comment #15 from sdc.bla...@youmail.dk --- (In reply to Timur from comment #13) > Help explanation in Entries for Evaluate up to level: > "Enter the maximum hierarchy level down to which objects are shown in the > generated index." > Unclear. And probably wrong. I am working on updating the help page for Entries (e.g., bug 153561), and have worked with the "Evaluate up to.." on the Type tab (bug 153596) -- so I can include this ticket as part of that work. But.... ....it is still unclear to me what the "expected" behavior is. Have tried to understand the "actual" behavior for now (and then can evaluate whether changes are needed and/or whether a question should be raised about "expected" behavior). My best hypothesis at present is that the actual behavior of "Evaluate up to level" is to specify (from the top) how many levels of numbering are shown. Note that STR in comment 14 set "Evaluate..." to 1, which gave the desired result of showing the "Chapter" (outline level 1) heading number. One way to test this hypothesis is: 1. make a document with numbered headings for (say) 5 outline levels, then 2. insert a TOC. (Do not need to add a Chapter No., can just use the one included in the default Entry structure). By default, "evaluate..." is set to 10. Actual: all numbering levels are shown for all entries (default) 3. Edit index, change "evaluate..." to 3 (for level 2,3,4,5) -- if you have used headings at 5 levels. Actual: Up to three levels of numbering will be shown. (e.g., level 3, 4, and 5 entries show level 1 no./level 2 no./level 3 no., while level 2 headings show level 1 no./level 2 no., and level 1 shows level 1 no. iow - a more accurate label of actual behavior might be: "show up to outline level" X But this is only an empirical hypothesis -- would be better to have someone confirm that the hypothesis is consistent with the source code. Note: There seem to be some other quirks with these indexes, sort of like being in one state (e.g, where things don't update when options are changed), but after it comes into another "state", then changing options gives expected results. This experience is sort of consistent with the report here about different behaviors with different versions. In some cases, I just inserted a new index, and then things worked as expected. Sorry -- cannot systematically reproduce this problem -- so just leaving this "warning" for those who will test the hypothesis here. -- You are receiving this mail because: You are the assignee for the bug.
