Currently, when we generate a ToC, an Alphabetical Index etc. - we introduce a special kind of entity, which is demarcated; and may be auto-updated; and may be protected etc. I suggest we offer the possibility of performing this generation as a "one-off", with the result just being plain contents that we put in the document. Motivation: * Reduces the constraints on users who want to play around with the generated contents or its layout. * Makes it easier to introduce (e.g. by extension) other kinds of generation, as one does not have to account it would be interactively manipulated during visits. * May allow, in the future, getting rid of the chimera of a manually-editable-yet-updateable tables and indices. See bug 169210, comment #9 and that bug more generally.
Indices are fields, and as commented in bug 169210 it seems odd to "protect" a field which nature is to be variable. You can always copy and paste special, however... Anyway, this is not a topic for UX and actually a duplicate of the other bug.
(In reply to Heiko Tietze from comment #1) > Indices are fields, Well, I propose that we support generating an index or a table-of-contents as _not_ a field. If you think it's relevant, I could generalize this to a suggestion for generating what would be the contents of _any_ field as merely regular non-field contents. Then it would be like asking for a functionality which is a bit like "rasterize" for vector layers in photo editors: Do the automatic thing one last time, then hand off the result to the user completely. > as commented in bug 169210 it seems odd to "protect" a field which nature > is to be variable. There's changes by the user and changes by the app. Some entities are intended for just one of those two, and some for both.