Re: testing for a remote file to include file on a Windows mappeddrive

[Stefan Monnier]

>> For the "/:" file-name handler, file-remote-p should return nil, and
>> unhandled-file-name should return the filename with the "/:" stripped.
>> For url-handler-mode, the "file://" should not be considered remote
>> either and unhandled-file-name should return the filename with the
>> "file://" stripped.

> I've got it: we were speaking about different functions. You need a
> function which converts a file name to an argument which can be passed
> literally to a *local* subprocess.

> I was speaking about trimming a file name, which can be used then as
> argument by *any* subprocess, either local, either remote
> (`process-file' or `start-file-process').

> Both functions might be useful.

Hmm... I see your point and now I'm not so sure about the function
I propose.  I always thought that for process-file and
start-file-process, the best option was always to use
file-relative-name, but then the same argument should apply to my
file-local-name.  So the main missing feature is to figure out whether
that relative name will work, which depends on whether
unhandled-file-name-directory returns something that works or not.

I suggest to change unhandled-file-name-directory so that it can (and
should) return nil if the named file/directory cannot be
directly accessed.  And then let users of unhandled-file-name-directory
default to "~/" if it returned nil.  Then we can define file-local-name
as follows:

  (defun file-local-name/unhandled-file-name (file)
    (setq file (expand-file-name file))
    (let ((dir (unhandled-file-name-directory file)))
      (if file (expand-file-name (file-name-nondirectory file) dir))))

or alternatively, we can add file-local-name/unhandled-file-name and
drop unhandled-file-name-directory (which can be defined then as

  (defun unhandled-file-name-directory (file)
    (unhandled-file-name (file-name-directory (expand-file-name file))))


        Stefan