Bug 127007 - Editable field "Data range:" associated with the context menu of any Chart wall treats its list separator badly: Confusion.
Summary: Editable field "Data range:" associated with the context menu of any Chart wa...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
6.3.0.2 rc
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-08-18 12:55 UTC by Wolfgang Jäger
Modified: 2021-08-19 08:02 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
shortly demonstrating details, in specific what I called "funny effects" (49.99 KB, application/vnd.oasis.opendocument.spreadsheet)
2019-08-18 15:33 UTC, Wolfgang Jäger
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Wolfgang Jäger 2019-08-18 12:55:01 UTC
(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?
Comment 1 m.a.riosv 2019-08-18 13:44:58 UTC
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.
Comment 2 Wolfgang Jäger 2019-08-18 15:33:02 UTC
Created attachment 153483 [details]
shortly demonstrating details, in specific what I called "funny effects"
Comment 3 Wolfgang Jäger 2019-08-18 15:33:45 UTC
(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.
Comment 4 m.a.riosv 2019-08-19 08:48:38 UTC
(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.
Comment 5 QA Administrators 2021-08-19 03:44:47 UTC Comment hidden (obsolete)
Comment 6 Wolfgang Jäger 2021-08-19 08:02:00 UTC
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.