Re: Change in expand-file-name in Emacs
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
>>>>> "Kai" == Kai Großjohann
<kai.grossjohann(a)gmx.net> writes:
Kai> Maybe you want to do this in XEmacs, too?
Possibly. Why would such a path arise in practice?
Who's to know?
And why expand it via a file-handler? I thought normally those
would be invoked later, inside the file handling functions.
expand-file-name *is* a file operation.
That is, expand-file-name is documented as a text rewriting function
("note that these simplifications are done without checking the
resulting file names in the file system"). Suppose that you had
/foo/bar/../../no-such-user＠host:~/x/y
instead. Does your function DTRT (ie, ask host to look up
~no-such-user and signal a sensible error)?
Given the above file name, the old version would see that the file
name is not special. So it would do the ".." dance and return the
string "/no-such-user＠host:~/x/y". The new version does this, as
well, then sees that "/no-such-user＠host:~/x/y" is a special name and
so it invokes the handler.
So the new version, when given
"/foo/bar/../../no-such-user＠host:~/x/y" as input, behaves the same
as the old version, when given "/no-such-user＠host:~/x/y" as input.
And is that _really_ TRT? (Ie, do we want to do such a lookup
here---this would be very annoying if you had something like
(setq my-global-home (expand-file-name "me＠home.net:~"))
in init.el and you were offline.)
ITYM "/me＠home.net:~", with the leading slash?
The behavior of expand-file-name in this case hasn't changed.
Kai> Apologies if this message was inappropriate.
Not at all, very welcome in fact. Except that in theory, since it's
not a bug it might be better directed to xemacs-design.
OK, will do that next time.
--
A preposition is not a good thing to end a sentence with.