[Top][All Lists]

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

Re: locale encoding and core functions

From: John W. Eaton
Subject: Re: locale encoding and core functions
Date: Sat, 9 Mar 2019 13:03:13 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1

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:


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?


reply via email to

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