Re: substitute-in-file-name is not distributive

[Daniel Colascione <dancol@dancol.org>]

[-- Attachment #1: Type: text/plain, Size: 3844 bytes --]

On 10/30/2012 11:58 AM, Stefan Monnier wrote:
>>> Hmm... that's odd.  Can you give me some details:
>>> - tell me exactly which text you typed in the minibuffer.
>> I typed "c:\bin\" in the minibuffer and hit tab. After hitting tab, the
>> minibuffer contained "c:/usr/bin", with point at the end.
>>> - also tell me how the rfn-eshadow highlights the file name at each step.
>> Now that you mention it, I do see that the leading "c:" in the
>> minibuffer is highlighted.  That explains why we're substituting
>> "c:/usr/bin" and not "/usr/bin".
> 
> Right.
> The "c:" is highlighted because (s-i-f-n "c:\\bin") = (s-i-f-n "\\bin").
> Now the problem is that when you replace \bin by /usr/bin suddenly that
> same rule doesn't apply any more.
> 
> Hmm... I think the core of the problem here is that minibuffer
> completion is actually only performed on "the current field" which is
> usually the whole minibuffer content, but not with rfn-eshadow.
> To fix this, we should invert the relationship between
> minibuffer-complete and completion-in-region (i.e. minibuffer-complete
> should call completion-in-region rather than the other way around).
> This would probably be a good change, but we can't do it for 24.3.
> 
> You should be able to work around this problem by removing "field
> shadow" from file-name-shadow-properties.

Doing that globally will break normal file shadowing, which we want to keep working.

>>> Right.  BTW I'm not convinced this is the right pattern to use for your
>>> file-name-handler.  I think catching "\\[a-zA-Z]:" or something along
>>> these lines might be a better choice.
>> Not all paths I want to catch are absolute,
> 
> Why not?  Which non-absolute file names [we only use "path" for lists
> of directories, as in $INFOPATH] would you need/want to rewrite?
> Do you just want to replace \ with / in relative file names or is there
> more to it?

Remember that the mapping of Cygwin names to Windows ones is *arbitrary*. Any
approach that's based on "replacing slashes" is prone to failure. To a Cygwin
Emacs, it's as if Windows file names were written in encrypted EBCDIC. Emacs
must treat Windows filenames as opaque blobs to be passed to
cygwin-convert-path-from-windows.

Relative file names come up during builds. Say I'm editing foo.c and the build
system outputs "objchk\x86\foo.o" in some message: I want to be able to append
this relative path and get back a full Cygwin path.

>> Even "absolute" paths can be drive-letter-relative and begin with
>> a simple backslash.
> 
> Right, that's what triggers the above problem.
> 
>>> BTW, does Cygwin allow backslashes in file-names or does it interpret it
>>> as a separator, like Windows does?
>> Cygwin interprets backslashes as separators.
> 
> So Cygin itself treats "\\bin" and "/bin" as equivalent

No --- Cygwin treats "\\bin" just as Windows would: it's a drive-letter-relative
Windows path. "/bin" is a perfectly normal POSIX path.

> , but your
> rewrite rules treat "\\bin" as a Windows file name and rewrite it to
> "/usr/bin"?

Yes.

> If you limit yourself to:
> - rewrite "\\`[a-zA-Z]:" to "/cygdrive/c" (regardless if it is followed

Not all Cygwin installations use "cygdrive". Every instance of the word
"cygdrive" in Emacs is a bug.

>   by backslashes or forwardslashes).
> - rewrite \ to / everywhere.
> This should cover the main needs without tripping over the above problem.

This approach doesn't work either. The resulting POSIX file names alias the same
files named with mounted Cygwin paths.

"/cygdrive/c/bin/ls.exe" and "/bin/ls.exe" refer to the same file, but because
the paths differ, Emacs will consider these as two distinct files. Also, access
semantics differ between drive-prefix-prefixed paths and native Cygwin paths.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]