Re: Multibyte and unibyte file names

[Eli Zaretskii <eliz@gnu.org>]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: emacs-devel@gnu.org,  Kazuhiro Ito <kzhr@d1.dion.ne.jp>
> Date: Wed, 23 Jan 2013 20:42:55 +0100
> 
> >      (defun tramp-handle-file-name-directory (file)
> >        "Like `file-name-directory' but aware of Tramp files."
> >        ;; Everything except the last filename thing is the directory.  We
> >        ;; cannot apply `with-parsed-tramp-file-name', because this expands
> >        ;; the remote file name parts.  This is a problem when we are in
> >        ;; file name completion.
> >        (let ((v (tramp-dissect-file-name file t)))
> > 	 ;; Run the command on the localname portion only.
> > 	 (tramp-make-tramp-file-name
> > 	  (tramp-file-name-method v)
> > 	  (tramp-file-name-user v)
> > 	  (tramp-file-name-host v)
> > 	  (tramp-run-real-handler
> > 	   'file-name-directory (list (or (tramp-file-name-localname v) ""))))))
> >
> >     which on Windows means that, e.g.
> >
> >       (let ((file-name-coding-system 'cp1252))
> > 	(file-name-directory "/eliz@fencepost.gnu.org:漢字/"))
> >
> >        => "/eliz@fencepost.gnu.org:  /"
> >
> >    And there are other similar handlers in Tramp (e.g., the
> >    file-name-nondirectory handler) which do the same.  IOW, they seem
> >    to _assume_ that the corresponding "real" handler never needs to
> >    encode the file name.  A false assumption.
> 
> Tramp is not prepared to handle encoded file names.

I didn't try to imply it should.  Tramp should not, however, delegate
its handlers' job to "native" implementations, because those cannot,
in general, be assumed to DTRT for the remote host.

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.

> 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.

> 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"?

> 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?