Kai> Maybe you want to do this in XEmacs, too? Possibly. Why would such a path arise in practice? And why expand it via a file-handler? I thought normally those would be invoked later, inside the file handling functions. 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)? 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.) 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. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.

Kai> Maybe you want to do this in XEmacs, too? Kai> "Stephen J. Turnbull" <stephen(a)xemacs.org&gt; writes: Kai> Who's to know? Well, since to my mind the semantics of looking up "~" for remote hosts (which may not even grok the concept) are questionable, I'd like to know where this is going. I think it's very reasonable to have a facility which does completion etc on remote paths for interactive use, but non-interactive, I don't know about that. I've never seen an expand-file-name call wrapped in a condition-case. ;-) So I'd like to see examples where it's useful, so I can wrap my brain around intended semantics. Also, I'm not sure that I agree that the proper interpretation of "/x/../me＠home.net:/~" is "/me＠home.net:/home/me". That's mixing two different purely textual manipulations. It's so subtle I'm not even sure it matters ... but it makes me nervous. Kai> expand-file-name *is* a file operation. As far I can tell from the documentation, it's intended to be an operation on strings. It is not supposed to actually attempt to look up the path on the system. I suppose it's reasonable to interpret that you should look up the user name on the remote system, but it's equally reasonable to interpret that as an attempt to access the path (which is not necessary for a local name; although lookups in /etc/passwd or whatever access the file system, they do not attempt to access any part of the path being computed, except / of course ;-). On systems using NIS or similar, this might not even involve any file system lookup by XEmacs at all! Kai> ITYM "/me＠home.net:~", with the leading slash? Yes. Kai> The behavior of expand-file-name in this case hasn't changed. Blech. You're right. I can only imagine that there are no practical non-interactive situations in which this is desirable, or we would have had bug reports about bogus net accesses when disconnected. (Note that in that case expand-file-name will throw an error (I assume; it throws one for a non-existent host) and thus if you have such an expression in init.el, the init file breaks.) Lack of such reports (init file or in general) suggests people hardly ever use this feature of expand-file-name. Anyway, you're obviously making things more consistent since EFS does provide a handler for expand-file-name, and on that basis I won't object to a patch to 21.5 if you or someone else submits one. (I may however produce a counter-patch to avoid this behavior, at least to be user-configurable.:-) -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.

Kai> It seems I misunderstood. I thought you were only talking Kai> about the ".." interpretation. But it turns out you're Kai> talking about the interpretation of "~" for remote files. What I'm interested in is the semantics of remote file name expansion, in particular, the _error_ semantics if the remote system is not accessible. Kai> What should be the result of "/x/../me＠home.net:/a/b"? Kai> Maybe you're proposing that it should return Kai> "/:/me＠home.net:/a/b". I'm not proposing that, although I think it's very reasonable to suppose that /a/.. is / on localhost. What I'm worried about is _unreasonable_ alternatives, interactions among file handlers and the like, and operations that don't succeed. (Examples below.) I'm also worried about the fact that this means that file handler regexps that are written to be anchored at / are not. Kai> But what I meant by saying it's a file operation is that Kai> expand-file-name looks to see if its arg matches a regexp Kai> from file-name-handler-alist. This does not necessarily Kai> imply any disk access. It just implies that file handlers Kai> can provide their own implementation of expand-file-name. OK. Kai> Which path? The path being expanded. Kai> Okay. Here's another one; maybe this example convinces you. Kai> It does not use "~" at all. No example that _succeeds_ is going to convince me. I can see that the semantics proposed here on success are useful. What bothers me is coming up with reasonable semantics on _failure_, which is going to be fairly common (eg, if you're attempting to access Al Jazeera assets this week). Kai> This means that people who wish to use EFS to access another Kai> host which just happens to provide an AFS filesystem, and Kai> said people would like to access that, then they need to use Kai> "/user＠host:/../some/file". Yuck! Who thought of that? But ... either EFS handles this purely textually, or you should never hang on to the result of (expand-file-name "/user＠host:/../some/file") (because if AFS happens to be offline when you expand-file-name, and EFS checks whether it's there, and it's not, and the next handler reduces /user＠host:/../ to /, you'll never be able to get access without reinitializing the app). Kai> IMHO, expand-file-name on "/a/../something" should be the Kai> same as expand-file-name on "/something". Well, how about "/luser＠parasite:/../user＠host:/../foo"? And how about if that is written (expand-file-name "/user＠host:/../foo" "/luser＠parasite:/..") or (concat "/luser＠parasite:/.." "/user＠host:/../foo") Presumably that is how you're going to get paths of the form you're talking about. Kai> You were also talking about interactivity. It's not quite Kai> clear to me what that means. Why is it important whether Kai> expand-file-name is invoked after the user hits TAB in the Kai> C-x C-f prompt or at some other time? Because when it fails (and if it attempts to access remote hosts, it _will_ fail, sooner rather than later), in the interactive case there's someone who can (for almost all values of "Emacs user" :-) pass a reverse Turing test to repair things. In the non-interactive case (eg, init.el) bad things can happen before something intelligent can intervene. I guess what I really want most is restrictions and/or finer control on what expand-file-name handlers can do. But I still have some questions about the semantics of the feature you're proposing. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.