If your document has some regular content, then a generated table or index (e.g. a ToC), then some more content; and if you make a selection starting before and stopping after the table or index - you should be allowed to delete your selection. Instead, if you delete (e.g. by pressing the Delete key on your keyboard) you are told that "Write-protected content cannot be changed". This is: 1. Confusing, since the selection may be very long (dozens of pages) and you don't even know what the message is talking about. 2. Nonsensical, since it's not as though you're trying to delete _part_ of the index or table, you're deleting all of it. so, such deletion should simply be allowed. I'd say that even if you select just whole table/index and nothing else - you should already be allowed to delete it. I believe this behavior has been around since forever, but I don't remember exactly.
You can disable "Protected against manual changes" (https://help.libreoffice.org/7.4/en-US/text/swriter/01/04120211.html). It makes little sense to modify auto-generated content. But maybe I havent got the issue as "the selection may be very long (dozens of pages)" is weird.
(In reply to Heiko Tietze from comment #1) > You can disable "Protected against manual changes" > (https://help.libreoffice.org/7.4/en-US/text/swriter/01/04120211.html). It > makes little sense to modify auto-generated content. This bug is about letting regular deletion work even when "protected against manual changes" is on, because you're not making a _change_, you're deleting the table, just like you could with a right-click and choosing "Delete" on the menu. I do want protection about manual _modification_ of a ToC or Index, not against removing it altogether. > But maybe I havent got the issue as "the selection may be very long (dozens > of pages)" is weird. That was just to say that if I start selecting at some point, move down a couple dozen pages, and press delete, I haven't even noticed there might be a generated table in the middle, so I wouldn't even know why I'm being informed about "write-protected content".
(In reply to Eyal Rozenberg from comment #2) >... move down a > couple dozen pages, and press delete, I haven't even noticed there might be > a generated table in the middle, so I wouldn't even know why I'm being > informed about "write-protected content". Isn't exactly this an example why the current safety mechanism should be kept? My take is NAB/WF.
(In reply to Heiko Tietze from comment #3) > Isn't exactly this an example why the current safety mechanism should be > kept? No, this is not what the safety mechanism is for. The safety mechanism is intended to prevent making _changes_ to a generated table - because even though it has internal content, we want it to be considered as a single entity; and it gets re-rendered occasionally when we update, so we don't want to give the user the idea that they should edit the ToC/index themselves. There is no problem with deleting a generated table and we don't want to protect against that. The way this restriction is applied simply hinders the use of selection, deletion and overwrite mechanics.
(In reply to Eyal Rozenberg from comment #4) > No, this is not what the safety mechanism is for. The safety mechanism is > intended to prevent making _changes_ to a generated table - because even > though it has internal content, we want it to be considered as a single > entity; and it gets re-rendered occasionally when we update, so we don't > want to give the user the idea that they should edit the ToC/index > themselves. There is no problem with deleting a generated table and we don't > want to protect against that. I do not support that reading - sorry :) The dialog for indexes, offers a checkbox to turn protection off/on as well. > The way this restriction is applied simply hinders the use of selection, > deletion and overwrite mechanics. It does. Then the users checks, uses context-menu for index, etc. Anyway, that is my suggestion.
(In reply to Cor Nouws from comment #5) > I do not support that reading - sorry :) > The dialog for indexes, offers a checkbox to turn protection off/on as well. No, it does not. The dialog offers a checkbox to protect against "Manual changes". Nobody would interpret that as preventing deletion. > > The way this restriction is applied simply hinders the use of selection, > > deletion and overwrite mechanics. > It does. > Then the users checks, uses context-menu for index, etc. > Anyway, that is my suggestion. That is not what the user intended to happen when inserting the table or index. In fact, it is the _opposite_ of what the user intended. And if you think of a long document with multiple generated tables (e.g. one per section) - it is not possible to delete a large part of the document without a very long visitation procedure.
We discussed the topic at the design meeting. At creation time and later it is possible to unset the protection flag. And the context menu provides delete. So we decided to not change the behavior. Comment from the mailing list: > It's not a safety measure, since these tables/indices are generated content, which can later be re-generated. In fact, it is _safer_ to delete a generated table/index than any other piece of content. True, the argument is weak. But still there are enough means to achieve what you want.
(In reply to Heiko Tietze from comment #7) > We discussed the topic at the design meeting. At creation time and later it > is possible to unset the protection flag. And the context menu provides > delete. So we decided to not change the behavior. > > Comment from the mailing list: > But still there are enough means to achieve what you want. Ah, but what I want is to delete a long stretch of a document without having to perform a lengthy sequence of operations. And it's not just what "I want" - it's what the typical user pressing Delete wants. And you cannot assume that these users are supposed to, apriori, decide they want to allow arbitrary changes to the table, just so that in some point in the future, a person who may not even be them, would not have trouble deleting multiple tables/indices. I believe that, UX-wise, you're adopting surpising and undesirable default behavior due to a mis-reading and over-reading of user intent when not unchecking a checkbox in the creation dialog.
Created a "compromise" suggestion bug report: 152111.
We discussed this topic again in the light of an option at bug 152111. Such an option does not much clutter the UI but is hard to understand. Delete means to remove the ToC but it is unclear when exactly (when hitting Del at any position?), but when protection is off the deletion would be done on the context. So an option is not so good. What I personally would agree on is to delete (protected) ToC if the selection includes the whole ToC like known from tables. But I'm also fine with WF since ToCs show up in the Navigator and can be deleted easily there.
(In reply to Heiko Tietze from comment #10) > What I personally would agree on is to delete (protected) ToC if the > selection includes the whole ToC like known from tables. This is exactly what I've asked in the opening comment. And speaking of regular tables, I said in the design meeting the other day that it makes little sense for user-generated table content to have less protection against deletion than auto-generated table content, which can always be regenerated if necessary. So, let's do just this :-)