If I have "Chapter" numbering numbering defined in my document (which is of course not chapter numbering, that's a misnomer, it's heading/outline numbering), with a "before" or "after" separator, and I set the numbering style to "None" and press Ok - I still get the separators rendered. That's not reasonable and not what the user would expect. One of two things should happen: 1. Separators get disabled when no numbering style is used for the level, i.e. there may be a setting, but it's not used. 2. One can still define "dummy" separators for the level, but changing the numbering scheme to "None" sets the before and after separators to be empty, so that one would need to manually insist on dummy separators. I prefer (1.), (2.) is tolerable.
Created attachment 188125 [details] 156089_prefixSuffixForNONE.odt I assume this document expresses what you are describing. I suggest NOTABUG, since DOC/X also seem to work this way.
In reply to Justin L from comment #1) "DOC/X" ? Do you mean Microsoft Office? MSO's behavior is not the standard by which we judge what's valid and appropriate; rather, it is an approach we consider. In this case, it does make sense to remove the before- and after-separators, and the user does not expect, nor need, dummy/phantom separators with no number.
ODF allows this and I see no harm in this flexibility. "None" just doesn't mean no numbering but no (automatic) numbers/chars. Agree with Justin on NAB.
(In reply to Heiko Tietze from comment #3) > ODF allows this and I see no harm in this flexibility. "None" just doesn't > mean no numbering but no (automatic) numbers/chars. Agree with Justin on NAB. I did not suggest that the user not be able to insist on these, i.e. I did not suggest the separator textboxes be cleared _and disabled_. I'm just saying that the assumption regarding the common case is wrong, so that the textboxes should be _cleared_.
(In reply to Eyal Rozenberg from comment #4) > I did not suggest that the user not be able to insist on these, i.e. I did > not suggest the separator textboxes be cleared _and disabled_. Actually, that is exactly what you suggested for option 1) Option 2 isn't unreasonable. https://gerrit.libreoffice.org/c/core/+/153975 It just is "helpful" to the user by clearing the prefix/suffix in the UI. [By default the prefix/suffix is empty, so the user probably has already specified something, so one could argue that they should also be responsible to clear it. But I agree that 99% of the time the user's intention is to clear everything when turning off number.] I tested what happens if "include previous levels" was enabled. When setting the last level to NONE, then the previous levels are also not shown. So that fits with "very likely the user doesn't want the prefix/suffix either".
(In reply to Justin L from comment #5) > Option 2 isn't unreasonable. https://gerrit.libreoffice.org/c/core/+/153975 I wouldn't touch manually entered data. Maybe reasonable but likely unexpected, at least if you accidentally switch to None.
(In reply to Heiko Tietze from comment #6) > clearing is likely unexpected, at least if you accidentally switch to None. Yes, that was the one example I could think of where this would not be desirable. I couldn't think of any other reason why someone (who had defined numbering previously) now wanted to keep the suffix after turning off numbering. I'm not too worried about "bothering" someone who makes a mistake, or accidentally changes something.
(In reply to Justin L from comment #5) > Actually, that is exactly what you suggested for option 1) Oh no, that's true! :-( Justin, Heiko - I'm sorry! I mistyped... I prefer option (2.) > [By default the prefix/suffix is empty Well, not if you pressed the "Numbered List" button on the toolbar, or applied one of the list styles with prefixes/suffixes.... (In reply to Heiko Tietze from comment #6) > I wouldn't touch manually entered data. Maybe reasonable but likely > unexpected, at least if you accidentally switch to None. The prefix or suffix is a single character or a pair of characters, it's not some long stretch of text which the user might "forget" or anything, so I don't share that aversion. However - I have two alternatives for you to consider, if you insist: 1. Well, if it's that important, you can "save" the prefix and suffix for non-"None" options, and restore them if you change from "None" back to something else. We do this in Format | Character... | Position , for the Superscript and Subscript options vs the Normal option. 2. How about if we only deleted it when the user had _not_ manually set the values since last arriving at the pane?
(In reply to Eyal Rozenberg from comment #8) > 1. ... "save" the prefix and suffix Remembering the prefix solves the problem where users scroll through the options but I don't buy the use case. You may exactly want to use None with some prefix (sure, there might also be situations where you don't) - and any modification is unwanted. > 2. How about if we only deleted it when the user had _not_ manually set the > values since last arriving at the pane? You probably mean settings made in a previous session. Sounds like a lot of work for no good reason.
(In reply to Heiko Tietze from comment #9) > (In reply to Eyal Rozenberg from comment #8) > I don't buy the use case. You may exactly want to use None with > some prefix - and any modification is unwanted. I was replying to your use case of "you accidentally switch to None." This use case you now claim - does not exist. Why? Using "none with some prefix" means using a fixed symbol which doesn't advance with additional paragraphs; that is called: A bullet. I challenge you to demonstrate a reasonable use case in which anyone wants to use No-numbering with a prefix, and a bullet is not more appropriate. > > 2. How about if we only deleted it when the user had _not_ manually set the > > values since last arriving at the pane? > You probably mean settings made in a previous session. No, I don't. We could do that too, that's a third alternative. But we could just add a couple of "edited while pane is in focus" booleans to the code, which, when true, guard these fields against being reset. That said, I agree with your claim that it > Sounds like a lot of work for no good reason. ... and actually believe it is of basically zero use to maintain the prefix and suffix settings when you switch to None. I believe you are throwing up nonexistent or super-niche use cases to defend the surprising and cumbersome behavior in the common use case.
We discussed the topic in the design meeting. Following the comments here we agree on the WF/NAB verdict. Any automatic processing needs a strong justification and benefit for users. Clearing the before/after entries is not such.
Created attachment 190999 [details] changeNumbering1.docx: numbering defined by "Heading numbering". (In reply to Heiko Tietze from comment #11) > We discussed the topic in the design meeting...we agree on the WF/NAB verdict. I (though not part of the meeting) should probably go on record as not agreeing with NAB. I just re-found this report as I tried to file a duplicate. This document really confused me: -open changeNumbering1.docx -select everything (Ctrl-A) and turn off numbering (F12) or (Ctrl-Shift-F12). The number disappears, but the period stays. VERY AWKWARD AND PUZZLING. Of course, even if we clear the prefix/suffix, we still get strange results. On the toolbar, the "Toggle Ordered Lists" icon will still indicate "active", and toggling will do nothing (although selecting a specific choice will work). I still recommend clearing prefix/suffix when numbering type changed to NONE via these UNO commands.
I'm returning to this bug after several months, so let me add a bit more info, plus reply to multiple comments. So, first piece of info: We get this undesirable behavior when pressing the (already-pressed) numbering button on the toolbar. It's one thing not to clear the Prefix and Suffix values in the dialog - but when the user presses the already-pressed numbering button, they express a clear intent of wanting to remove the numbering completely - certainly not to leave behind a suffix and prefix. So, it turns out that the prefix and suffix do disappear, if you choose "Graphic" or "Bullet" for example, accept, then open the dialog again. That means that we don't strongly hold on to these settings anyway. (In reply to Justin L from comment #1) > I assume this document expresses what you are describing. Only in the sense that it has Heading numbering with a suffix. But the text of the document doesn't. (In reply to Heiko Tietze from comment #11) > We discussed the topic in the design meeting. Following the comments here we > agree on the WF/NAB verdict. Let's quote the design meeting comments supporting this conclusion: > + works like in MSO, WF (Justin) > + no reason to block, WF (Heiko) > + behavior existing for years shouldn't change without > good reasons (Hossein) > + list style is something you shouldn't change multiple times > => resolve WF Justin has changed his opinion (making it a draw in terms of people involved in the discussion). I didn't understand Heiko's comment - block what? Re Hossein's comment: It's a long-standing bug, which has annoyed users for all this time, at least in the toolbar button use-case I mentioned above. Re the last comment: That argument works both ways: If you don't do this a lot, you shouldn't mind typing in your suffixes or prefixes. Also, we actually do remove numbering multiple times using the toolbar button (as opposed to fiddling with list style specifics). So I am un-resolving. Also, we now have a third possible resolution: Different behavior when selecting None in the dialog and when pressing the numbering button on the toolbar. We can have the former maintain and the latter drop the prefix and suffix.
(In reply to Eyal Rozenberg from comment #13) > Let's quote the design meeting comments supporting this conclusion: > > + works like in MSO, WF (Justin) > Justin has changed his opinion I think comment 5 and comment 7 show that I never considered this a WF once the issue was clarified, so the meeting's assessment of my opinion was wrong. I even provided a patch that solves the problem...
(In reply to Justin L from comment #14) > the meeting's assessment of my opinion was wrong. Comment 1: => NAB (In reply to Eyal Rozenberg from comment #13) > I didn't understand Heiko's comment - block what? To suppress None being a list style (see comment 3) (In reply to Justin L from comment #12) > This document really confused me: > -open changeNumbering1.docx > -select everything (Ctrl-A) and turn off numbering (F12) or (Ctrl-Shift-F12). The Heading 1 style has an outline assigned _and_ a list. You remove the list but keep the outline (as shown in the Style Inspector). It's in fact awkward that the usual list style off functions don't work as expected. Pressing the toolbar button has no effect. The "No List" style works not for multiple paragraphs but for one only. The convenience feature works not well in this case, obviously. Mike, what do you think? And I wonder if this is a regression.
(In reply to Justin L from comment #12) > This document really confused me: changeNumbering1.docx solved by bug 159054