Re: Multibyte and unibyte file names

[Michael Albinus]

Eli Zaretskii <address@hidden> writes:

> For example, in the particular case of file-name-directory, I think
> Tramp should simply do its job by a straightforward removal of the
> portion after the last slash in Lisp, instead of calling the native
> implementation.

This would duplicate code. I try to avoid, when possible.

>> I agree, Tramp shall check carefully what a file name encoding is. This
>> must be added to the code.
>
> Sorry, I don't follow.  File names in Lisp are not encoded in any
> way.  You only need to encode them when you pass them to commands
> executed on the remote host, and decode the results that are output by
> those remote commands.

Maybe there's a misunderstanding here. But you gave an example with a
file name with japanese codings.

>> There might be a chance to switch to en_US.UTF-8 on the remote side. But
>> even here I would propose to start with the unibyte subset. "en_US",
>> because Tramp parses the output of commands, which must not be
>> localized.
>
> Why "must not be localized"?

Tramp does not understand German messages, for example. "de_DE.UTF-8"
would be a no-go. That's why Tramp sets the remote locale to English
messages. Currently it is "C", it could be "en_US.UTF-8" in the
furure. But I don't know, whether all remote hosts are already prepared
for UTF-8.

>> Other encodings but UTF-8 will be hard to support. It is not only that
>> Tramp calls "native" file name primitives, there are also several
>> parsing routines for commands on the remote side, which have their
>> expectations on file name syntax and their encodings.
>
> I'm afraid I don't follow here, either.  Emacs is well equipped to
> do code conversions from and to almost any encoding out there.  The
> only problem is to know which encoding to use when communicating with
> the commands on the remote host.  What am I missing?

Maybe one could teach Tramp to convert file names in whatever coding to
UTF-8. But shall we do it? And how would that work with other Emacs
flavors? Yes, I must keep XEmacs in mind.

Best regards, Michael.