[Octave-bug-tracker] [bug #47571] Problem with umlaut in command line

[anonymous]

Follow-up Comment #14, bug #47571 (project octave):

There seem to be two different issues.

One is how Octave represents multi-byte chars internally, where Latin1 chars
take up to 2 bytes and Chinese chars take up to 3 bytes. This has
ramifications for string comparisons, strfind, strrep, etc. It looks bizarre
at first but having variable width characters is common in most Unicode /
localization efforts. The hard part is preventing false positives. For
example, umlauted characters have the leading byte 195, so searching for
character 195 returns true even if character 195 is different.

The other is how to enter extended chars at the command line and how that
varies across different platforms. It looks like most Windows installations of
Octave cannot accept umlauts even if Windows itself can. Is there code in the
Octave interpreter that rejects characters outside a certain range even if
they're inside string delimiters? If not, where are the umlauted chars going?
Are they just not being displayed or are they not entered in the command
buffer at all?


    _______________________________________________________

Reply to this item at:

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

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/