[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:
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
- Re: locale encoding and core functions, Andrew Janke, 2019/03/04
- Re: locale encoding and core functions, Markus Mützel, 2019/03/09
- Re: locale encoding and core functions, Andrew Janke, 2019/03/09
- Re: locale encoding and core functions,
John W. Eaton <=
- Re: locale encoding and core functions, Andrew Janke, 2019/03/09
- Re: locale encoding and core functions, John W. Eaton, 2019/03/09
- Re: locale encoding and core functions, Mike Miller, 2019/03/09
- Re: locale encoding and core functions, John W. Eaton, 2019/03/12
- Re: locale encoding and core functions, Andrew Janke, 2019/03/12
Re: locale encoding and core functions, Carnë Draug, 2019/03/10