Proposed restructuring of gnuplot's LC_NUMERIC locale code

[Ethan M. <merritt@u.washington.edu>]

Bug #1692541  points out an error in the current locale processing.

The current logic is the following:

  - "set decimal locale" causes gnuplot to reset it's numerical
    formatting according to the value of LC_NUMERIC in the current
    environment.  The LC_NUMERIC settings include the decimal point
    character, the thousands separator character, and the grouping
    of digits in long number strings. This affects all libc
    formatting functions, in particular printf() and sprintf().

  - These settings remain in effect until explicitly cancelled,
    e.g. by "unset decimal" or "set decimal locale 'C'".  All
    string output that uses the C library routines therefore
    uses the new decimal point, thousands separator, etc.

  - However, the program itself temporarily resets the locale to "C"
    in various  save_<foo>()  show_<foo>()  and other routines that
    result in executable commands.  

  - Unfortunately the locale setting also affects terminal driver
    output as well as the core routines.  This was unintended.

It's probably my fault, but before I mess things up any further I
thought I would open the issue for discussion.  There are two obvious
approaches to fixing this.

(1) Temporarily revert to locale "C" inside the affected terminal
    drivers, just as we are currently doing in the core routines.

(2) Invert the logic everywhere:  Leave the locale as "C" by default
    and temporarily switch to the requested environment locale when
    writing axis labels, tick labels, user labels, titles, and
    probably some other things I am not thinking of. 

Approach (1) has the advantage of leaving the core code unchanged.
However it is unpleasant to think of potentially setting/resetting
the locale for every point or line segment plotted.  I don't like
this option.

Approach (2) is more obviously correct, but involves changing the
core routines.

As a point of reference, here are the affected terminals:

>>> grep -c '%\.[0-9]f' *.trm | grep -v :0
ai.trm:15
aquaterm.trm:1
cairo.trm:2
corel.trm:14
fig.trm:2
hpgl.trm:27
latex.trm:12
metapost.trm:22
mif.trm:6
next.trm:7
openstep.trm:7
pdf.trm:2
post.trm:16
pslatex.trm:5
pstricks.trm:7
svg.trm:19
tgif.trm:125
x11.trm:1

And here are the core routines whose current logic
would need to be inverted:
>> grep -c LC_NUM *.c | grep -v :0
command.c:8
gplt_x11.c:1
mouse.c:6
save.c:1
scanner.c:3
set.c:2
show.c:6
unset.c:1

I don't have a list yet of the core routines that would need
new code to set/reset the locale during operation.
Perhaps the list contains only write_multiline() and gprintf()?

-- 
Ethan A Merritt