[Octave-bug-tracker] [bug #57235] Character encoding problems

[Markus Mützel]

Update of bug #57235 (project octave):

                  Status:               Need Info => In Progress            
                 Release:                   5.1.0 => dev                    

    _______________________________________________________

Follow-up Comment #4:

Thanks, for your explanation.

jwe is currently working on a replacement for the command window which will
hopefully fix the issue you describe in comment #3.

Wrt your comment #2: That is a corner case we haven't covered yet.
There are actually two issues that are causing the current behaviour:
1. Octave doesn't know the encoding that is used to read .m files so early on
in the start up process. I don't know how to fix this in Octave though.
As a work-around you could use two startup files called in a row. The first
startup file (.octaverc) is used to set the .m file encoding:

__mfile_encoding__ ("utf-8");  # or whichever encoding you prefer
clear ("functions");   # necessary (?) to re-read the .m files in the correct
encoding
second_octaverc;


Put the non-ASCII code in a second startup file (second_octaverc.m):

addpath ('C:\Türkçe');


Another work-around that you could use: Save the .octaverc file in your system
encoding (likely "Windows-1254"?).


2. However, the above work-arounds currently fail because of another issue.
There is still some code that isn't Unicode-aware on Windows. I am currently
working on a fix for that and waiting for the cross-compilation to finish.



    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?57235>

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