[Octave-bug-tracker] [bug #53842] Handle m-files with arbitrary character encoding

[Andrew Janke]

Follow-up Comment #11, bug #53842 (project octave):

I'm wondering if this feature may actually be detrimental to the Octave user
community, because it would allow (and maybe encourage) users to create M-code
that is incompatible with M-code in other encodings.

Let's say I'm collaborating on a project with someone in Latvia and someone in
China, and each of them have their systems set up to use their local
non-Unicode encodings. I don't think there's a way for me to configure my
Octave system in a way that the source code from both of them could be used in
a single Octave session, if the source file encoding is a global Octave
setting.

Perhaps it would be better to require that all Octave M-code source files be
in Unicode encodings, or at least make that the default on all operating
systems. That way all Octave .m code bases would be interoperable with all
other Octave .m code bases, at least by default.

Using the system default code page would require users to be aware of the
interoperability issue, and take explicit action to create their source code
in Unicode format. That seems like an advanced operation that normal Octave
users shouldn't have to be aware of.

Along the same lines, perhaps this:

> static std::string Vmfile_encoding = "utf-8";

should be a more generic "unicode" encoding, like this:

> static std::string Vmfile_encoding = "unicode";

to allow for easier integration of future support for autodetected UTF-16 and
UTF-32 files?

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?53842>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/