substitute-in-file-name is not distributive

[Daniel Colascione]

I wrote a bit of code to handle Windows paths in being given to
read-file-name in a Cygwin Emacs --- it's just a simple
file-name-handler-alist entry that overrides substitute-in-file-name
for Windows paths to yield the corresponding Cygwin path. Why not view
Windows path syntax as a funky way to "quote" Cygwin paths? This
approach works fine, except for completion.

The trouble is that the core completion code makes unwarranted
assumptions about the behavior of expand-in-file-name. Specifically,
completion--tqw-all assumes that (equal (unquote (concat (qnew foo)
(qnew bar)) (unquote (quote (concat foo bar))). Why should that be the
case?

In my mockup, I'm trying to complete 'c:\'. I have a 'c:\bin';
converting the path 'c:\bin' to Cygwin yields "/usr/bin" on my
machine. The trouble is that when we try to get all the completions
for 'c:\', which "unquoted" is '/' on my machine. completion--tqw-all
wants to paste '/' and 'bin' together to yield '/bin', but my s-i-f-n
handler returns '/usr/bin', so completion--qw-all's last cl-assert fails.

I don't think it's fair to assume that substitute-in-file-name
distributes over all components of a path. Unfortunately, simply
removing the assertion causes mysterious failures elsewhere. The
assumption of a distributing s-i-f-n seems baked into the code.

Is there another way to do what I want here?

signature.asc
Description: OpenPGP digital signature