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.