Re: Tcl9: source files are interpreted as utf-8 by default

Luc <luc@sep.invalid> wrote:

On Fri, 10 Jan 2025 06:38:02 +0000, eric wrote:
 

The 8.6 way is wiser. 

 

Not sure... your choice of encoding may not be the one of your
application users.
In this case, your code may fail to load in the user's encoding choice.

**************************
 
The user's choice is and always will be a point of uncertainty.
 
Tcl9 introduces an additional uncertainty with the developer.

Actually, 9 /reduces/ uncertianty.

Current method:

Developer: sets his system encoding to ISO-8859.  Writes Tcl script,
and includes 8859 code points directly into the script.  everything
works for developer, on his system.

User #1: sets his system encoding to CP437 (the original DOS character
encoding -- I needed to pick 'something' other than 8859).  Downloads
"Developers" script from github, and launches it.

If Tcl interprets the script using the sysstem encoding, it will
interpret the ISO-8859 script as if it were DOS CP437 bytes.  So many
extended language letters will instead become lots of line draw
characters (just one example).  The user is disappointed, as the script
does not work "out of the box" for him.

New Tcl9 method:

All Tcl scripts are UTF-8, no exceptions (not really true, but close
enough).

Developer: Must create the script with UTF-8 encoding.  Note, the
'developer' could continue to use 8859 for 'writing' things, they
simply must use iconv (or similar) to convert to UTF-8 before feeding
the script to the Tcl interpreter.

User #1:  Continues setting his/her system encoding to CP437.  But now,
they download developer's script from github, and when they launch it
with Tcl9, it is always interpreted as UTF-8.  It "just works", and
User #1 sees the proper accented characters the developer put into the
script for prompts or other strings.  User #1 did not have to do
anything, and the script worked "out of the box" for him/her.



With the Tcl9 method of "all scripts must be UTF-8" there is less
uncertianty, because the script will be interpreted using the same
encoding everywhere, no matter what odd local system setting any given
user may have chosen.