[Octave-bug-tracker] [bug #62807] dir_encoding: report the actual encoding independent of whether it has been in the load path

[Colin Macdonald]

URL:
  <https://savannah.gnu.org/bugs/?62807>

                 Summary: dir_encoding: report the actual encoding independent
of whether it has been in the load path
                 Project: GNU Octave
               Submitter: 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: 
        Originator Email: 
             Open/Closed: Open
                 Release: dev
         Discussion Lock: Any
        Operating System: Any


    _______________________________________________________

Follow-up Comments:


-------------------------------------------------------
Date: Sun 24 Jul 2022 11:11:14 PM UTC By: Colin Macdonald <cbm>
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?







    _______________________________________________________

Reply to this item at:

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

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