[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Octave-bug-tracker] [bug #62807] dir_encoding: report the actual encodi
[Octave-bug-tracker] [bug #62807] dir_encoding: report the actual encoding independent of whether it has been in the load path
Sun, 24 Jul 2022 19:11:15 -0400 (EDT)
Summary: dir_encoding: report the actual encoding independent
of whether it has been in the load path
Project: GNU Octave
Submitted: Sun 24 Jul 2022 11:11:14 PM UTC
Category: Octave Function
Severity: 3 - Normal
Priority: 5 - Normal
Item Group: Feature Request
Assigned to: None
Discussion Lock: Any
Operating System: Any
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:
p = pwd ()
# 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
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:
Message sent via Savannah
- [Octave-bug-tracker] [bug #62807] dir_encoding: report the actual encoding independent of whether it has been in the load path,
Colin Macdonald <=