[Octave-bug-tracker] [bug #49685] Set .m file encoding on a per-directory basis

[Markus Mützel]

Update of bug #49685 (project octave):

                  Status:         Patch Submitted => In Progress            

    _______________________________________________________

Follow-up Comment #20:

If the encoding that is used to read some .m file functions is changed, I see
no way around re-parsing them (which is essentially the same as `clear
THAT_FUNCTION`). That entails resetting persistent variables

After the first attempts on this, I'm starting to have doubts if using the
`PKG_ADD` script is the best way to go ahead anyway. I like the approach of
getting the file encoding when a directory is added to the path. That way the
dir_encoding can be read and stored only ones instead of trying to get that
information for each file that is parsed.
But when this information is provided with `PKG_ADD`, what seems to be
happening is:
1. Parse all files in the new directory (including PKG_ADD).
2. Execute the PKG_ADD script (which might call `dir_encoding`).
3. Parse all files in the new directory again if the encoding has changed.
(This has to be done manually with the current patch.)

Parsing the functions twice is not very efficient. And parsing the files with
the wrong encoding in step 1 might lead to unexpected side effects (parse
errors). Having functions that `mlock` themselves might also be problematic
with that approach.

It would probably be better imho if the following happened when a new
directory is added to the load path:
1. Look for a special file (that doesn't need to be parsed by Octave) in the
new directory. Read and set the `dir_encoding` from information gathered from
that file.
2. Parse all files with the *correct* encoding.
3. Potentially call the `PKG_ADD` script (or do whatever we decide
elsewhere).

That's close to what Andrew proposed in comment #14.

Maybe that file could be named `.oct_settings`. That way we could add other
directory specific settings in the future. (No idea what that could be. But
who knows...)
The file itself could contain strings (one setting per line) that are easy to
parse.
E.g.:

encoding=UTF-8


Does that approach look reasonable?


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?49685>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/