unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Daniel Colascione <dancol@dancol.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: substitute-in-file-name is not distributive
Date: Wed, 10 Oct 2012 10:40:34 -0700	[thread overview]
Message-ID: <5075B312.8060409@dancol.org> (raw)
In-Reply-To: <83a9vuz1o1.fsf@gnu.org>

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

On 10/10/12 10:18 AM, Eli Zaretskii wrote:
>> Date: Wed, 10 Oct 2012 09:48:21 -0700
>> From: Daniel Colascione <dancol@dancol.org>
>> CC: emacs-devel@gnu.org
>>
>> Cygwin itself deals adequately with being given Windows paths ---
>> it's Emacs that could handle them more elegantly.

It's important to note that the Cygwin and Windows path trees can be
completely disjoint. Cygwin has its own mount table. I have my system
configured so that there's a close resemblance between the two
hierarchies, but it doesn't have to be so. c:\foo could map to
/qux/bar/spam/blah.

> If Cygwin can handle these file names (which is what I thought was the
> case), why not change expand-file-name so that the DOS_NT parts there
> are also compiled in for Cygwin?
> 
> Hmm... but then typing "C-x C-f /foo/bar TAB" will prepend a drive
> letter, perhaps, which is not what you want.

Right. I suppose I could change the code so that we understand both
kinds of path but prefer POSIX ones, but the approach I have in mind
feels more elegant. What happens with my s-i-f-n handler is that
read-file-name accepts Windows paths and (when completion works)
completes them, but as soon as the user accepts a path, it's converted
to a Cygwin path and remains as a Cygwin path through the rest of
Emacs. It's pretty elegant in practice.

If we do nothing, Emacs treats Windows paths as opaque blobs. From
Emacs' point of view, if you try to find-file c:\etc\passwd when
default-directory is "/etc", you're asking Emacs to find the file
"/etc/c:\\etc\\passwd". That's not right.

There are three approaches to solving the problem:

1) Modify the DOS_NT code so that Cygwin Emacs can parse Windows
paths. Pass all paths to Cygwin and let Cygwin sort them out. This
approach will configure the hell out of other bits of code that assume
that we have Windows paths IFF (memq system-time '(windowsnt dos)).
It also complicates file-directory-name and friends.

2) Explicitly reject Windows paths and provide a way for the user to
trigger path conversion. This approach strikes me as inconvenient.

3) Use a s-i-f-n hook to convert paths to Cygwin ones. This approach
works well enough aside from the completion breakage. One way to deal
with the completion problem would be to build completions based on the
*Windows* path, not the Cygwin path, but it wasn't apparent to me how
you could convince the code to do that. There's no
file-name-handler-alist handler for "build me a set of completions,
but before you call substitute-in-file-name."




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

  reply	other threads:[~2012-10-10 17:40 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 [this message]
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
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

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5075B312.8060409@dancol.org \
    --to=dancol@dancol.org \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    /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 public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).