Oh, no, no, no, come on... I know I wasn't in the session (which I couldn't since it was in the middle of a workday), but - there had been extensive discussion on the bug pages, and the session itself seems to have just ignore it all. This is really exasperating.
------------------------------------------ > * Autocorrect replaces " - " with " – " instead of " — " > (en-dash instead of em-dash) > + typically two hyphen is an EN-dash, three EM (Heiko) I've explained several times on the bug page that this bug is not about when people are trying to explicitly express a choice between the two kinds of longer dashes. > + two dashes with / without spaces is kind of standard and > working like this in MSO (Hossein) Same point. Heiko had definitely read the bug page, so he should have known this already; Hossein - perhaps the bug was mis-described in the Jitsi session and you didn't have the time to read the comments? > + maybe drop the conversion of single hyphen (Stuart) (This is not a misinterpretation, but it may be inspired by the misinterpretation above) Of course not drop the conversion of a single hyphen! That's an very important autocorrect feature: Most people use minus/dash because they are unaware of the different types of dashes, or because they don't know / haven't thought about how to insert different kinds of dashes (or because they're lazy). This autocorrection helps improve the typesetting quality of the work of "lay users". > + clearly described in > https://help.libreoffice.org/latest/en-US/text/shared/01/06040100.html 1. It clearly says in the help page that space,minus,space is replaced with space,en-dash,space. Which is the behavior I'm suggesting be changed. 2. Help contents is never a justification for a choice of behavior of the app itself. > + two dashes without spaces like 1--2 is not correctly > converted (Heiko) That's interesting - but unrelated to this bug. Open a separate bug... No "bug hijacking" with something which is clearly not part of the scope of the original bug. > => bug; do not change the behavior as described in the help How does this conclusion relate even to what you guys were saying before?! And other than Stewart's position (which I disagree with but nullifies the question in this bug) - none of the discussants even tried to argue that it is better for text to have space,en-dash,space's instead of space,em-dash,space's. ------------------------------------------
* Support distinction rather than override of conflicting subdocument styles + https://bugs.documentfoundation.org/show_bug.cgi?id=155740 + unclear use case (David) + some confirmation per document (Shu) + if we better go with a global master switch (Heiko) + master documents are a special workflow aiming for style consistency, WF (Mike, Hossein)
No, they aren't. A single document is the workflow for absolute style consistency. Master documents are workflows for composing a larger document from smaller documents, _which well be valid documents on their own_.
+ unclear use case (David)
Second time this is said. Actually, third time, since this was said on the bug page, and I clarified. What about that did not seem clear?
+ copy/paste could solve alternative workflows (Shu)
If it could, we wouldn't need master documents in the first place. And, again, that's just a repetition of points which had been made, and rebutted, on the bug page. To make them again, one must address and reject the rebuttal. -------------------------------------------
* When setting the Heading/Outline Numbering for a level to "None", still getting separators + https://bugs.documentfoundation.org/show_bug.cgi?id=156089 + works like in MSO, WF (Justin) + no reason to block, WF (Heiko) + asking to _clear_ the separator fields in case of None (Eyal) + remembering "Chapter/:" is not a (good) solution since users may change it for None into "-/>", or the like, making it very difficult to follow + behavior existing for years shouldn't change without good reasons (Hossein) + list style is something you shouldn't change multiple times
Less frustrated about the objections here, but - the basic argument, which was not rebutted, is that our current behavior is the opposite of what the user expects to happen. An especially problematic argument is "this has been the behavior for years". Most of the bugs we consider in the design sessions are about behaviors LO has had for years. That's not an argument against addressing them, it's just a sign of the limitation of our resources. -- To unsubscribe e-mail to: design+unsubscr...@global.libreoffice.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.libreoffice.org/global/design/ Privacy Policy: https://www.documentfoundation.org/privacy
