(I did not yet check which historical versions of Calc did this first. Most likely the behaviour was introduced together with the "option setting dependence" of the separator to be displayed in function parameter lists. The default separator there depends on the locale.) Context: The second station of the Chart wizard and the context menu of any Chart wall (item "Data Ranges...") give access to an editable field labelled "Data range:". The field should accept a list of AbsoluteName of SheetCellRange (where the sheet name may be entered without the "$" but will always be interpreted as absolute). Observation concerning Chart: This field wrongly and EXCLUSIVELY uses and ACCEPTS only the separator defined under >Tools>Options>LibreOffice Calc>Formula>section "Separators">label "Function:" which is to be used as the list separator in parameter lists when a formula is displayed. Using that separator also for the display of lists of AbsoluteName of SheetCellRange may be acceptable regarding the general mess made of anything in Office software, though it is bad and helps users to misunderstand things even more. But... Observation concerning Formula: For the input / editing of formulae, however, the semicolon is still accepted AND THIS BEHAVIOUR SHOULD PERSIST eternally. EXPECTED behaviour concerning CHART: The default list separator of LibreOffice Calc which is the semicolon should at least always be ACCEPTED during input/editing the DataRanges of a Chart. Please note: The DataRanges of a chart aren't a parameter list at all, and the popular nonsense-sheetnames are now anyway allowed to contain any of the usual separators (",", ";", ".") in word positions. No reason to prefer a localised / personalised separator. Those who don't understand the context should cease to directly edit DataRanges. CURRENTLY the mentioned separator setting only refuses to accept the arithmetic operators. IT ACCEPTS even the COLON and the AMPERSAND e.g! Very funny effects! Suggestion: Shitcan that option! The related code cannot be made "intelligent" on the fly. Addendum: The very bad idea to use the comma as the list separator also for lists which may contain constant numbers written with a decimal separator was introduced without serious considerations when the first "languages" for writing human-readable programs were created (mid 1950es at IBM) in an English-only environment. Because the scene was completely professional then, everybody knew about the limitations and accepted a syntax implementing habits based on usage in English as a matter of fact in the field, and even the more thoroughly designed ALGOL family took on the bad model. StarOffice also did it for its BASIC later, but was clever enough to NOT do it for Calc. Nowadays people without any specific education ar encouraged to sometimes act as "programmers", writing Calc formulae e.g. Will there be remedy concerning the separator mess?
Seems the issue of not to accept semicolon as separator is their since the introduction of the option to change formula separators with: LibreOffice 3.3.0 OOO330m19 (Build:6) tag libreoffice-3.3.0.4 I don't know why for the case of chart data ranges it needs to be showed or allows a different separator than the default semicolon. But maybe for some people having something different than their usual office it's annoying. I any case not allowing semicolon seems a bug. Please rephrase the title to be a more concise about the issue.
Created attachment 153483 [details] shortly demonstrating details, in specific what I called "funny effects"
(In reply to m.a.riosv from comment #1) > Seems the issue of not to accept semicolon as separator is their since the > introduction of the option to change formula separators with: > LibreOffice 3.3.0 OOO330m19 (Build:6) tag libreoffice-3.3.0.4 > > I don't know why for the case of chart data ranges it needs to be showed or > allows a different separator than the default semicolon. ... Though conflicts are not expected as long as there only AbsoluteName(s) of SheetCellRange can occur, the case should not be treated differenly, imo. Next enhancement might (should) be to allow there for calculated ranges like the 'Validity' tool does for a long time now. There were more than one questions in forums not having a satisfying answer without such a new feature. > ... But maybe for some > people having something different than their usual office it's annoying. Hmmm. In the 1970es I read a lot about the didactics of mathematics. I still remember a statement by Hans Freudenthal (https://en.wikipedia.org/wiki/Hans_Freudenthal) which would, roughly translated to English from memory look something like "We should't teach mathematics mainly regarding the students specifically easily getting confused." Trying to run a respective strategy concerning the design of general purpose software we might end up with confusing everybody - and knowing no remedy. To tidy up the mess with different decimal separators and with conflicts between one of them (the comma) and commonly used list separators is a task for institutions in charge of negotiating and defining international standards. This cannot be done by every/any/some programmers everywhere in the world independently. StarOffice and OpenOffice used the semicolon as the mandatory list separator which it still is when writing to the persistent representation (file). There was no GOOD reason to change that. The only argument which may have looked like a reason surely was compatibility with "en" versions of MS Office. Getting a bit more compatibility there accepting additional incopmatibility between local installs of "our" software may not pay. > In any case not allowing semicolon seems a bug. Another bug, SERIOUS though not likely to tumble over, is the acceptance of characters as separators clearly conflicting with other separators and operators. If the option is needed (and the discussion is over unfortunately) it MUST restrict the choice to characters NEVER occurring as (in) operators or at the edges of syntactical items probably getting in contact with the chosen separator. Explicitly excluded must be any of the characters in "+-*/%&<=>:!~#$'.(){}", the space, all the digits and letters, and every character without a classical ASCII code (up to X7E), or a code below X20 (control character) . The only characters I can find for a positive list are ";" and (hesitating) "|" and -if you think it's unavoidable- the damned comma. I attach a lttle example to explain what I called "fuinny effects" in my original post. > Please rephrase the title to be a more concise about the issue. Sorry. Would you try, please.
(In reply to Wolfgang Jäger from comment #3) > Another bug, SERIOUS though not likely to tumble over, is the acceptance of > characters as separators clearly conflicting with other separators and > operators. If the option is needed (and the discussion is over > unfortunately) it MUST restrict the choice to characters NEVER occurring as > (in) operators or at the edges of syntactical items probably getting in > contact with the chosen separator. Explicitly excluded must be any of the > characters in "+-*/%&<=>:!~#$'.(){}", the space, all the digits and letters, > and every character without a classical ASCII code (up to X7E), or a code > below X20 (control character) . The only characters I can find for a > positive list are ";" and (hesitating) "|" and -if you think it's > unavoidable- the damned comma. > There's no choice but to agree with you.
Dear Wolfgang Jäger, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Sorry for the too wory report/comment above. The main aspect of the bug dscribd concisely now: The list DataRanges... we get when editing a chart connected to spreadsheet data via the context menu of the wall, needs to accept specific separators. Currently only the separator set via Calc options '>>Separators>>function:' is accepted. The spreadsheets always accept the formarly mandatory semicolon in addition. Chart DataRanges also should. This bug is still living in 7.2.0.3 I didn't check for every related detail. Addendum (without thorough considerations): The factually appropriate fix might be to replace the list separator by the operator for reference concatenation ('~') for the 'DataRanges...' editor.