Re: locale encoding and core functions

[John W. Eaton]

On 3/9/19 12:07 PM, Andrew Janke wrote:
> On 3/9/19 10:10 AM, "Markus Mützel" wrote:
>
> > Your idea with .encoding files in each directory sounds promising. 
> > Maybe we should use ".mfile-encoding" or some other name more specific.
>
> Yes, ".mfile-encoding" or similar is better; ".encoding" is too generic 
> and there's no standard for it.
>
> > I'd rather not traverse up the directory tree to look for that file. 
> > When should we stop looking for that file? Should we traverse up until 
> > root? What should be done in case we reach a directory without read 
> > access?
> > I would also prefer to not parse each source file for a magic comment.
> > Both of these options also sound like they might impact first run 
> > performance.
>
> Now that I think some more, sticking with an .mfile-encoding for each 
> PATH entry is probably best. Octave projects tend to have few source 
> dirs, so it's not a burden on users. Avoids your performance concerns, 
> easier to code, and it won't interact in surprising ways with 
> .mfile-encoding files that users stick elsewhere in their directory tree 
> (which might not be included in source control! e.g. maybe a user thinks 
> editing ~/.mfile-encoding is the way to use it; now this feature is just 
> making things more complicated.).

If you would like to do this, let's consider making the file more 
generally useful.  We could also use it to store other per-directory 
information.  For example, we could mark directories as "traditional" so 
that full-on Matlab compatibility mode could be enforced, which could 
make a feature like warning/error for Matlab incompatibility actually 
useful.

Since the info only applies to directories in the load-path, the 
performance hit shouldn't be too high.  We already scan those 
directories at startup and rescan them when they change.  And the number 
of directories is not large.  Compare this with the .dir-locals.el files 
that Emacs uses -- they may appear in any parent directory of any file 
that Emacs opens, not just the files where .el files appear.

Also, here's how Emacs handles .dir-locals.el files:

https://www.gnu.org/software/emacs/manual/html_node/emacs/Directory-Variables.html#Directory-Variables

Note that it looks up the directory tree until it finds a .dir-locals.el 
file.  But since our search is limited to the load path, we wouldn't 
have to scan the filesystem each time this information is needed.  We 
could already have it cached in the load_path object.

In Emacs these directory local files normally set variables, but can 
also eval code.  Octave doesn't have variables in the same way that 
Emacs does, so we would have to decide whether we are willing to execute 
arbitrary code, a subset of functions, or just allow some limited number 
of settings/options.

Also in Emacs, I think that anything that can be set on a per-directory 
basis may also be set in each file by scanning for special comments. 
Would it also be worth doing that, at least for .m files that we already 
parse?

jwe