Noah Lavine <noah.b.lav...@gmail.com> writes:
> It seems like the right thing to do might be to do setlocale(LC_ALL,
> "") in Guile's main(). Let me argue that this accomplishes two goals
> which we want to accomplish
I agree wholeheartedly; this should be the default behavior. In the
rare cases where the user needs to avoid calling setlocale, they can
provide a different main().
Regarding backward compatibility: the current behavior already breaks
it. For most practical purposes, Guile 1.8 effectively accepts
command-line arguments in the current locale encoding (although it is
certainly broken with regard to its handling of character indices within
such strings). Guile 2.0 currently accepts only ASCII.
I don't see any sane way to preserve 100% backward compatibility with
the broken behavior of 1.8. It seems to me that calling setlocale in
Guile's main() is not only the right thing moving forward, but also the
most backward-compatible option that is reasonably sane.
Peter Brett <pe...@peter-b.co.uk> writes:
> That seems entirely reasonable to me, as long as libguile users can
> still set a non-environment locale before first entering Guile mode and
> have libguile respect that.
Setlocale would only be called within main() of the Guile executable.
It would never be automatically called within libguile, so any program
that contains its own main() in C would be responsible for calling
setlocale (if it chooses to).
> However, I'd still be concerned about the case where filenames are
> passed on the command line in an encoding that differs from the
> environment encoding. A few months ago, Mark mentioned that he was
> looking at "safe" encodings for filenames. I wonder if that's relevant
> to command-line argument processing?
I apologize for dragging my feet on this for so long. A few months ago
I argued forcefully for a particular approach to this thorny issue, and
then later had second thoughts. It is important to get this right,
because we will have to live with our chosen approach for a long time.
I hope to write another email on this subject soon.
Mark
