> From: David Kastrup <[email protected]> > Cc: [email protected], [email protected] > Date: Mon, 30 Jan 2017 20:00:03 +0100 > > Eli Zaretskii <[email protected]> writes: > > > One other crucial detail is that Emacs also has unibyte strings > > (arrays of bytes), which are necessary during startup, when Emacs > > doesn't yet know how to decode non-ASCII strings. Without that, you > > wouldn't be able to start Emacs in a directory whose name includes > > non-ASCII characters, because it couldn't access files it needs to > > read to set up some of its decoding machinery. > > Hm, I know that XEmacs-Mule emphatically does not have unibyte strings > (and Stephen considers them a complication and abomination that should > never have been left in Emacs), so it must be possible to get away > without them.
I doubt that's possible, at least not in general. (You could get away if you assumed UTF-8 encoded file names.) Some translation tables for some encodings must load files using the likes of load-path, and if that includes non-ASCII file names, you are screwed unless you can use unibyte strings. That is why all Emacs primitives that accept file names support both unibyte and multibyte strings as file names. > And I don't think that the comparatively worse Mule implementation > of XEmacs is due to that decision. Emacs 20 vintage Mule didn't have all the sophisticated Unicode support machinery we have today, so maybe for that subset the above wasn't necessary. Then again, Emacs couldn't be safely built or started in a non-ASCII directory until just a few years ago, so perhaps no one bothered to test that thoroughly with XEmacs, except in ISO 2022 locales.
