[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: locale encoding and core functions

From: Andrew Janke
Subject: Re: locale encoding and core functions
Date: Sat, 9 Mar 2019 14:24:38 -0500
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.3

On 3/9/19 1:03 PM, John W. Eaton wrote:
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.

Now that's kind of exciting. That could be the way that support for Matlab-compatible double-quoted string object literals gets in to Octave.

And maybe if it's going to be so powerful, it shouldn't be a hidden dot-file. Maybe "mcode.properties"?

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


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.

The idea of running arbitrary code in a pre-code-reading context is kind of scary to me. Especially because relative execution time & environment of this may depend on what order source files from different directories get called & loaded in. My gut says to stick with a predefined set of settings/options.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]