[Top][All Lists]

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

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

From: Markus Mützel
Subject: [Octave-bug-tracker] [bug #49685] Set .m file encoding on a per-directory basis
Date: Mon, 28 Sep 2020 13:38:06 -0400 (EDT)
User-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.121 Safari/537.36 Edg/85.0.564.63

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

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


Does that approach look reasonable?


Reply to this item at:


  Message sent via Savannah

reply via email to

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