At the moment, there is only one kind of ToC update: Recreating the entire ToC, getting rid of any manual changes which may have been made to it. But - it's possible the user wants to make manual changes, on the one hand, but not let the ToC become irrelevant due to typing some more content or removing some content elsewhere in the document - changes which only affect the page number, and are generally applicable without "messing up" the manual changes the user made to the ToC. I suggest we also support this partial kind of update. IIANM, Microsoft Word supports updating page numbers without recreating the entire ToC.
Created attachment 203880 [details] Table of Contents for testing.
Created attachment 203881 [details] Screenshot of ToC right-click.
Screenshot provided. Enhancement not yet implemented on 25.8.2.2. Request remains valid and would help preserve manual ToC modifications.
UX: encouraging manual manipulation of ToC doesn't make sense to me. What do you think?
(In reply to Buovjaga from comment #4) > encouraging manual manipulation of ToC doesn't make sense to me. That's a fair point, but - we do explicitly support this. The reasons seem to be some combination of history, imitation of MS Word's behavior, and the fact that it's often the case that the automatic layout of the ToC has some kind of issue with the results of tabulation, spacing, overflow etc., and the author may want to tweak it. Perhaps even use alter the item text slightly to improve the layout. Of course, it's good that others chime in about this as well, so thanks for setting the flag.
(In reply to Eyal Rozenberg from comment #5) > ... the automatic layout of the ToC has some kind of issue This does not justify a crooked function. -1
We discussed the topic in the design meeting. Besides Eyal's arguments about the workflow this feature is available in Microsoft Word and we there is no good reason to stand back.
Created attachment 205144 [details] Screenshot MS Word
Let me add an observation I made - in essence - during our design meeting. Let's forget about MS Word for a second, and even about page number updates. Now, why do people need to manually modify their Table-of-Contents, at all? There is the maximally-general argument of users just wanting to create some content, which the app does not understand/know about apriori, based on the ToC. Let's call that reason (1.). Well, this argument is rather weak; that is, it would probably not make sense to accomodate manual modification based on just that. Moreover, we could in principle offer the generation of a ToC which _cannot_ be updated, i.e. inject the generated content in the body of the document instead of into some special holding area with special handling; and this would address the desire to make arbitrary changes. But the more common reasons motivating the manual modifiability are, AFAICT, the following: 2. Addressing deficiences in the automatic layout (or formatting) of the ToC. I remember this from days of yore and MS Word: You would create a ToC, but some of the "..." between text and numbers would be placed weirdly; or their beginnings would not be aligned. Or - section titles would be broken at an inopportune point, and you would like to break them into to lines differently. 3. The desire to use different text for the in-body and in-ToC heading. For example, the in-body title might have some paranthetical text, or a long phrase taking up a full line or more than that; but for the ToC, the author can rely on the proximity of the parent heading, of child headings and of subsequent headings on the same level, to opt for something shorter. Currently, this is not achievable in LO (AFAIK) without manual ToC modification. When you engage in (2.) or (3.), and then type in some more content in your chapters and sections, or even just tweak the page margins a little for printing - page numbers change. And the user then wants to keep their modifications, on the one hand, and have tne page numbers brought up to date on the other. This is the rationale for the feature being available in MS Word. Now, if we could accommodate (1.) and (3.), i.e. structurally offer different ToC text for headings (perhaps this would require an app-specific ODF tag?), and make the formatting, layout and line breaking robust enoguh that users don't need to go manual - then, we could just consider abolishing the chimera of updateable-yet-manually-editable ToCs. And this feature would become unnecessary too. Unfortunately, that "if" is still far from being realized; and in the mean time - the feature makes sense and should be straightforward to implement.