setting tcl_libPath doesn't change encoding search path

Logged In: YES
user_id=80530

Moved to "Feature Requests".

I think this functionality could be provided by
a package making appropriate use of Tcl_CreateEncoding(),
right? If so, I think some prototyping as a package
would be in order to work out the kinks before
modifying Tcl itself. If the package is good enough,
modifying Tcl itself may not even be necessary.

Logged In: YES
user_id=80530

OK, after reading Tcl_GetEncoding(3), my prior comment
might have slightly missed the mark. The request here
is not for access to create a new encoding, which is
already provided by Tcl_CreateEncoding.

Instead it is access to influence the search path of
the dynamic loading of encoding files by
Tcl_GetEncoding() that is sought. There is a mechanism
provided for this as well: lappend additional
directories onto the global list variable ::tcl_libPath.

And that is the point... ah look he's getting it
now! The documented purpose of tcl_libPath is
to influence the search path of Tcl_GetEncoding(),
but it doesn't in fact have that influence. And
that seems like a bug. Putting it back...

Logged In: YES
user_id=32170

Glad you got it! I was just trying to write a more
thorough explanation, but now it seems it boils down to

"setting tcl_libPath should adjust the encoding search
path, but it doesn't"

and either the above should be fixed or some other way of
setting the encoding search path should be provided.

thanks for taking a second look...

Logged In: YES
user_id=80530

Just don't confuse my "getting it" with a commitment
to provide an immediate fix! ;-)

Logged In: YES
user_id=32170

Changed bug summary to clarify what the problem is.

Logged In: YES
user_id=80530

I'm looking at this again, and it appears to me that
changing $tcl_libPath to affect loading of encodings
does not work, and never has worked.

Given that, I'm not inclined to make it work. I'd
rather create something better. The logic of having
any connection between the search paths for encoding
files and the value of some variable named tcl_libPath
is completely lost on me. It feels like the auto_path
mistake all over again.

I'd much rather add a new subcommand to [encoding],
perhaps [encoding searchpath] and make that work
as a means to set/query the set of directories searched
for encoding data files. That will require a TIP of
course. Vince, interested in helping me work that out?

Logged In: NO

Sounds like a good plan to me. Either way, it needs to be
documented that $tcl_libPath is effectively read-only, for
whatever it may be used.

I could help a bit, especially with testing, and especially
in 2-3 weeks time...

Logged In: YES
user_id=72656

I like the 'encoding path' idea as well (came to the same
conclusion myself when playing around in there). The whole
hard-coded encoding stuff is bad. Note that the path
should be absolute - none of this auto-appending 'encoding'
onto it as is currently done.

Logged In: YES
user_id=32170

Some rather odd obserations about tclEncodings.c, which
should probably be fixed/resolved at the same time:

tclEncodings.c and tclUnixTest.c both set and get the value
of the C
variable tclDefaultEncodingDir, and tclBasic.c frees up any
memory
associated with tclDefaultEncodingDir. There are also
public APIs
'Tcl_GetDefaultEncodingDir()', 'Tcl_SetDefaultEncodingDir
()'.

However, that C variable is not actually /used/ anywhere in
Tcl for
anything, and certainly not as a 'default encoding
directory'!

Logged In: YES
user_id=43494

Tclkit workaround:

If you're trying to add encodings for tclkit, see
http://wiki.tcl.tk/RegisterNewEncodingsAtRuntime which
explains how to copy encoding files int $tcl_library at run time.

Logged In: YES
user_id=79902

I have yet to see an [encoding path] TIP. Is there a likely
horizon for this document being submitted?

Logged In: YES
user_id=32170

For my part, I have no plans to submit such a TIP -- Vince.

Logged In: YES
user_id=72656

There should be no expectation that setting a magic var
changes the encoding path in Tcl currently. However, I do
plan a TIP for 8.5 of the form 'encoding path(s)|dirs', as
it is the Right Thing.

Logged In: YES
user_id=32170

Jeff: the Tcl documentation says:

"When \fBTcl_GetEncoding\fR encounters an encoding
\fIname\fR that has not
been loaded, it attempts to load an encoding file called
\fIname\fB.enc\fR
from the \fBencoding\fR subdirectory of each directory
specified in the
library path \fB$tcl_libPath\fR. If the encoding file
exists, but is
malformed, an error message will be left in \fIinterp\fR.
"

that certainly gives me the expectation that setting this
var will change the current Tcl encoding path. That's not
to say this behaviour is good, or that 'encoding
path(s)|dirs' is bad, just that Tcl does not follow its
current documentation.

Logged In: YES
user_id=72656

You have to make some assumptions that you are allowed to
set tcl_libPath in the first place, but the real problem is
that comment is wrong in just about every aspect. The
tcl_libPath should not be considered a valid var, should not
exist, and will likely be removed in any future version
because it's a bogus red herring.

What actually happens is that tcl_libPath is set to the
internal library path on startup, and never referred to
again. It is a for-reference-only variable. In that way
the docs are correct, it's the assumption that setting
tcl_libPath affects anything that is invalid.

Which of course leads to a better question ... do we just
want to manage the encoding directory, or allow some
Tcl-level access to read *and* set the library path?

Logged In: YES
user_id=80530

The false claims have been removed
from the Encoding.3 documentation.

A soon-to-be-written TIP will offer
a new method for scripts to control
the search path for *.enc files.

Logged In: NO

In Tcl 8.5, I see "unsupported::EncodingDirs" as a new
command. Is the plan (as per the 1 year old comment below)
to write a new TIP to expose this?

Logged In: YES
user_id=80530

yes.

feel free to use the [::tcl::unsupported]
version for now, and report any trouble
with it.