From: Daniel Colascione <dancol@dancol.org>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: Emacs development discussions <emacs-devel@gnu.org>
Subject: Re: substitute-in-file-name is not distributive
Date: Tue, 30 Oct 2012 13:12:36 -0700 [thread overview]
Message-ID: <509034B4.7020301@dancol.org> (raw)
In-Reply-To: <jwvehkflsfy.fsf-monnier+emacs@gnu.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 --]
next prev parent reply other threads:[~2012-10-30 20:12 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-10 5:36 substitute-in-file-name is not distributive Daniel Colascione
2012-10-10 6:39 ` Andreas Schwab
2012-10-10 15:31 ` Eli Zaretskii
2012-10-10 16:48 ` Daniel Colascione
2012-10-10 17:18 ` Eli Zaretskii
2012-10-10 17:40 ` Daniel Colascione
2012-10-11 3:25 ` Stephen Leake
2012-10-25 3:20 ` Stefan Monnier
2012-10-25 3:28 ` Daniel Colascione
2012-10-27 16:08 ` Stefan Monnier
2012-10-28 19:09 ` Stefan Monnier
2012-10-30 4:10 ` Daniel Colascione
2012-10-30 13:15 ` Stefan Monnier
2012-10-30 15:01 ` Daniel Colascione
2012-10-30 18:58 ` Stefan Monnier
2012-10-30 20:12 ` Daniel Colascione [this message]
2012-10-30 21:24 ` Stefan Monnier
2012-10-30 21:34 ` Daniel Colascione
2012-10-31 3:41 ` Stefan Monnier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=509034B4.7020301@dancol.org \
--to=dancol@dancol.org \
--cc=emacs-devel@gnu.org \
--cc=monnier@iro.umontreal.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.