Re: Change in expand-file-name in Emacs

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.