guile-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: guile can't find a chinese named file


From: tomas
Subject: Re: guile can't find a chinese named file
Date: Wed, 15 Feb 2017 11:10:33 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, Feb 15, 2017 at 10:54:06AM +0100, David Kastrup wrote:
> <address@hidden> writes:

[...]

> > Not easy.
> 
> If you tell Emacs that some external entity is in UTF-8, it will
> represent all valid UTF-8 sequences as properly decoded characters, and
> it has special codes for all bytes not part of valid UTF-8.
> 
> As a result, it works with valid UTF-8 perfectly as expected but will
> reproduce arbitrary byte streams thrown at it perfectly when decoding as
> UTF-8 and then reencoding into UTF-8 again.

Yes, Emacs is the text specialist.

It has taken years and a bunch of very smart, experienced and *patient*
folks to achieve that. But then Emacs has users who don't run away
screaming when the GUI widget shows funky stuff. They mostly go
"oh, that's interesting" :-)

(My point: not easy).

A Glib function (as a servant to Gtk) is trying to display a string
"correctly", even if that string is mixed (say Latin1/UTF-8) encoding.
It just can't. Not unless you throw heuristics and voodoo in, and you
don't want a library doing that behind your back.

> Guile is lacking this byte stream reproducibility when
> decoding/reencoding.  That makes it a whole lot less robust for dealing
> with externally provided material.

Definitely. Perhaps the Emacs approach might be the right one for Guile?

regards
- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlikKRgACgkQBcgs9XrR2kaYCwCeIvEPwGvCRsy1Tm+BRLuOMaV2
7kkAnjyoGca+RsKdr4SzMGdzQKf2hEhx
=mb3P
-----END PGP SIGNATURE-----



reply via email to

[Prev in Thread] Current Thread [Next in Thread]