Re: [Denemo-devel] Problem with wide characters on upgrading to guile 2.x

[Mark H Weaver]

Richard Shann <address@hidden> writes:

> On Tue, 2013-09-03 at 19:53 +0200, Thien-Thi Nguyen wrote:
> [...]
>>    pt_BR.utf8 is not a supported locale on your system.
>
> yes, that is why I chose it, so as to trigger the error. It is graceful
> handling of this error that I was after - it should default to
> untranslated, not abort the program.

I disagree.  If Guile does not know what encoding to use, that's a
serious error that should not be ignored, at least not by default.
Please keep in mind that Guile is used for many diverse tasks, including
scripts that are run when the user's not looking, e.g. cron jobs.  Guile
must not silently corrupt data, which could easily happen if it silently
ignores the error without knowing what character encoding to use.

For fully interactive programs, ignoring the error and defaulting to the
C locale (e.g. ASCII) is more reasonable, because any corruptions will
hopefully be noticed by the user.  To do that, please consider the code
that Ludovic suggested:

  (catch 'system-error
      (lambda ()
        (setlocale LC_ALL ""))
      (lambda args
        (format (current-error-port)
                "warning: failed to install locale: ~a~%"
                (strerror (system-error-errno args))))

However, it should be noted that if you do this, Guile 2 (unlike 1.8)
will still raise an error later if you try to read a byte outside of the
ASCII range, or if you try to write a non-ASCII character.

Note that Guile 1.8 conflated characters and bytes, like many older
non-i18n programs, and thus effectively chose Latin-1 by default.
However, since most modern GNU systems use UTF-8 by default (at least
outside of the CJK world) this guess is most likely wrong, and thus
likely to silently corrupt non-ASCII characters.

     Regards,
       Mark