bugGNU Octave - Bugs: bug #62807, dir_encoding: report the actual...


bug #62807: dir_encoding: report the actual encoding independent of whether it has been in the load path

Submitter:  Colin Macdonald <cbm>
Submitted:  Sun 24 Jul 2022 11:11:14 PM UTC
Category:  Octave Function Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Feature Request
Status:  None Assigned to:  None
Originator Name:  Open/Closed:  * Open
Release:  * dev Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup

Mon 25 Jul 2022 08:40:12 AM UTC, comment #2: 

To clarify: The original scope of that function was to define how the parser reads .m files.
After recent changes, it is also used to define how the text from files is read from the disc. That is somewhat out of the original scope. Maybe, that is where all the confusion is coming from?

Markus Mützel <mmuetzel>
Group administrator
Mon 25 Jul 2022 08:35:37 AM UTC, comment #1: 

> Perhaps I'm still missing the point of this command: the current behaviour smells like some internal tooling and yet its not `__dir_encoding__`...

Internal functions (padded in double underscores) might change their behavior and interface at any point without any deprecation notice. When I added that function, I figured it was important enough for downstream to give it a stable and documented interface. Maybe, that was a mistake...

The documentation of `dir_encoding` is clear to me. But I wrote that documentation. So there is definitely a bias.
Happy to see any suggestions.

Markus Mützel <mmuetzel>
Group administrator
Sun 24 Jul 2022 11:11:14 PM UTC, original submission:  

Following up from https://savannah.gnu.org/bugs/index.php?62780

> If the documentation of `dir_encoding` is unclear in that respect,
> updates to it are welcome. It currently contains the following sentence:
>> The directory encoding is automatically read from the file .oct-config when a new path is added to the load path (for example with addpath).
> Negate that sentence, and it says: "The encoding is not read from those
> files unless their path is added to the load path." (The current
> directory is always in the load path.)

I think we certainly need to emphasize this more.  Happy to help draft something...   But several other options:

1.  Change `dir_encoding` to return the actual encoding:

def dir_encoding(d):
    p = pwd ()
    cd (d)
    cd (p)

    # continue as currently.
    # (perhaps not with this precise implementation!)

2.  Change `dir_encoding` to return None (empty string I guess) when the answer is not yet known.  Rational: if I just want to know the default system encoding, there should be some other mechanism for that!

3.  Keep it as it, but WARN in the docs, ideally giving and example of how to use unwind protect to find out the answer most people would want here.

- - - -

Perhaps I'm still missing the point of this command: the current behaviour smells like some internal tooling and yet its not `__dir_encoding__`...

I feel like users are not going to care or appreciate whether or not they have ever been in the directory or not.  They just want to know what the encoding of a particular directory is (not was or will/might be).  I think the current command mixes the state of the filesystem with the state of some internal cache/database.

Maybe we could split into `__dir_encoding__` which behaves "as is"and a user-facing `dir_encoding` that is less mysterious?

Colin Macdonald <cbm>


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by cbm (Submitted the item)

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.


    No changes have been made to this item

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code