bug#14030: 24.3; expand-file-name expands remote file name on Windows incorrectly

[Michael Albinus <michael.albinus@gmx.de>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Michael Albinus <michael.albinus@gmx.de>
>> Cc: vidagabor@gmail.com,  14030@debbugs.gnu.org
>> Date: Sun, 24 Mar 2013 18:21:48 +0100
>> 
>> > So, somehow, compiling tramp-sh.el on Unix replaces the call to
>> > tramp-drop-volume-letter with nothing.  Perhaps the condition, viz.
>> 
>> Yes, that is intended. tramp-drop-volume-letter is not needed on GNU/Linux.
>
> ??? But byte-compiled files are supposed to be platform-independent.
> The release tarball includes all of the *.elc files, which were
> compiled on Unix when the release was tarred, and they are not
> recompiled when Emacs is built on Windows (or on any other platform).
> Now you seem to be saying that all the *.elc files need to be compiled
> as part of the build on the target platform.  I think this isn't a
> good thing.

Yes, you are right.

>> Does this mean, this declaration requests Tramp to be compiled on MS
>> Windows?
>
> No, it means tramp-drop-volume-letter has a bug that needs to be
> fixed, IMO.

The problem seems to be, that defalias is evaled during
byte-compilation. So I will revert the definition of
tramp-drop-volume-letter, that is is decided at runtime how it is
defined.

>> We shall repackage Emacs 24.3 for MS Windows then.
>
> Lisp files are not supposed to be recompiled on the target platform.
> They are architecture-independent, and are installed in a directory
> which can be shared among different architectures.
>
> Sorry, but I think this is a grave bug.

Yes. Unfortunately, all pretests for MS Windows were compiled on MS
Windows. So this hasn't been detected earlier.

What shall we do with Emacs 24.3 for MS Windows? I still believe, that
we must repackage it, and compile tramp.el on MS Windows.

Alternatively there could be an Emacs 24.3a with a changed tramp.el. But
this sounds too heavy to me.

Best regards, Michael.