bug#31376: 26.0.50; print-charset-text-property not honored

[Eli Zaretskii <eliz@gnu.org>]

> From: Helmut Eller <eller.helmut@gmail.com>
> Date: Mon, 07 May 2018 20:08:19 +0200
> Cc: 31376@debbugs.gnu.org, Andreas Schwab <schwab@linux-m68k.org>
> 
> On Mon, May 07 2018, Noam Postavsky wrote:
> 
> > Helmut Eller <eller.helmut@gmail.com> writes:
> >
> >> On Mon, May 07 2018, Andreas Schwab wrote:
> >>
> >>>> In GNU Emacs 26.0.50 (build 10, x86_64-pc-linux-gnu, GTK+ Version 3.22.11)
> >>>>  of 2017-08-15 built on caladan
> >>>
> >>> Worksforme.  Have you tried a current version?
> >>
> >> Same (wrong) result with the current version.  Maybe it's an issue with
> >> environment settings?
> >
> > I can reproduce this.  I see something about
> > PRINT_STRING_UNSAFE_CHARSET_FOUND in print.c, so I guess iso-8859-1 is
> > considered "unsafe"?
> 
> Apparently which charsets are unsafe depends on the current locale.
> 
> If I start Emacs with LANG=it_IT.UTF-8 emacs -Q, then the charset
> property is not printed.  Even though that locale is not installed and
> this warning is printed at startup:
> 
> (process:23336): Gtk-WARNING **: Locale not supported by C library.
>         Using the fallback 'C' locale.
> 
> With LANG=en_US.UTF-8 emacs -Q the problem is the same as for
> LANG=C.UTF-8.

Can someone see any difference between the value t and 'default', wrt
when/how the 'charset' property of strings is printed?

I think the behavior under the value of nil is actually intended for
'default', and the value of nil is not implemented.  So I think we
should have a change in print_check_string_charset_prop that sets the
PRINT_STRING_UNSAFE_CHARSET_FOUND flag whenever it finds _any_
'charset' property on the string.

Comments?