This is solved by changeset dff830c84726 for bug #49685:
https://hg.savannah.gnu.org/hgweb/octave/rev/dff830c84726

For the originally motivating example (`help sym`), the output is correct even if the mfile encoding is set to "system" (the default; "CP1252" on my Windows machine) when I add a file ".oct_config" with the following content to the package directory:

encoding=utf-8

Adding those files to the packages should be tracked in separate bug reports.

Closing as fixed.

Might not be able to postpone this too long: work on bug #55452 has checked in non-ASCII characters in the BIST code (e.g. http://hg.savannah.gnu.org/hgweb/octave/rev/ccea3574f36b) and that's probably subject to the same encoding considerations as help strings.

There may also be an issue with assuming that doc strings are encoded in UTF-8 while the file itself is in a different encoding: text editors don't handle files with mixed encodings. So you wouldn't be able to properly edit these when running in a non-UTF-8 locale if the source files are in system-default encoding.

I had a look at the code for the lexer/parser again and  couldn't find anything that would indicate whether a file is from core Octave, an (OF) package or from a directory added by the user.

Maybe it would be handy if we would keep track of this. E.g., we cannot warn at the moment if a user (unintentionally) overwrites a core function if it is an .m file. Maybe "load_path" should distinguish if a file is "internal" or "external". And that information could be fed down to the parser (via "fcn_file_in_path"?).

Since this would be a bigger change and non-ASCII characters never really worked correctly on previous version of Octave anyway (on non-UTF-8 systems), this change should probably be postponed until after the Octave 5 release.

TL;DR:
Character encoding strikes again. Does the lexer keep track of whether .m files are from core?



When Octave is configured to use an mfile_encoding other than UTF-8, help text of function files that are encoded in UTF-8 is displayed with odd characters. On Windows, this happens with Octave's default settings. Other systems aren't affected by default (but only if the user configures to use a different encoding).

E.g.: "help sym" displays a lot of scrambled characters. That is because that file is encoded in UTF-8 but we assume it to be encoded in the configured mfile_encoding. Converting it from SYSTEM (CP1252 in my case) to UTF-8 creates these odd characters.

This is a regression. (Before, we didn't worry about encoding but had problems handling string vectors from user functions or interacting with the file system.)

That conversion is done in input.cc in function "file_reader::get_input".
Can we differentiate between .m files from the core or packages (which probably always are UTF-8) on the one hand and user created .m files (which could have any encoding) on the other hand at that point? Does the lexer keep track of this?

What about texinfo settings such as "@documentencoding UTF-8"? Should we parse for them and do the conversion only conditionally?
Should we skip the help text in the conversion completely? In that case, we might have to move the conversion elsewhere (to the lexer?).

Alternatively, we could revert the conversion in "help.m" (only if we discover an "@documentencoding" command?) for functions from the core or from packages.

But text in strings in functions from core Octave or from packages are probably encoded in UTF-8 as well (independent from the current mfile_encoding). So we shouldn't convert functions from core or packages at all and only do the codepage conversion on user functions.

This might also affect how we should open function files from core Octave (or from packages) in the embedded editor.