[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

substitute-in-file-name is not distributive

From: Daniel Colascione
Subject: substitute-in-file-name is not distributive
Date: Tue, 09 Oct 2012 22:36:21 -0700
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/20120907 Thunderbird/15.0.1

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

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?

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]