[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: problems with emacsclient started by cygwin programs (mswindows)
From: |
Stefan Monnier |
Subject: |
Re: problems with emacsclient started by cygwin programs (mswindows) |
Date: |
Mon, 04 Jul 2011 11:15:37 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) |
>>> I'm not sure I understand exactly what you're saying: is it because of
>>> limitations of cygwin-mount or is it because something else makes it
>>> impossible for cygwin-mount to do the right thing?
> The latter, I think. cygwin-mount is for translating valid cygwin
> pathnames into something that the native (non-cygwin) emacs can use.
> /c/foo/bar.el becomes c:/foo/bar.el.
> The problem I'm trying to solve is this: a cygwin program (e.g. git)
> calling emacsclient in a subdir of ~ will pass something like
> /home/user/foo.el to emacsclient. When emacs gets it, it calls
> expand-file-name on it like this:
> (expand-file-name "/home/user/foo.el" nil) =>
> "c:/home/user/foo.el"
> That's an invalid pathname. More importantly, it is outside the realm
> of cygwin-mount because this is not a cygwin-style path. It's a
> native windows path that is invalid.
Then I don't understand: what should be the right return value of
(expand-file-name "/home/user/foo.el") and how could Emacs figure it out?
In any case, this is unrelated to my comment "you can solve your problem
with something like cywin-mount.el", where I didn't mean "use
cygwin-mount.el" but just use something that works in a similar way,
i.e. by changing the behavior of things like expand-file-name, hence the
behavior throughout Emacs rather than only at the boundary between Emacs
and the calling program.
>>> I can't imagine why the same problem wouldn't show up if you try to run
>>> `emacs' from cygwin's bash.
>>> And please understand that I don't mean to say that your suggestion is
>>> wrong, just that the same should be done in startup.el to match your
>>> change in server.el.
> You've completely lost me here, sorry. (I don't mean this in a
> critical way, I just don't grok what you're saying.)
IIUC your problem shows up when you run "emacsclient ~/foo.el" from
Cygwin bash and I'm saying that it would show up just the same if you
run "emacs ~/foo.el" from that same bash.
>>> > most situations. Just not when I'm in a subdir of ~ where bash
>>> > reports my directory as /home/... and not /c/cygwin/home/... the
>>> > latter would be handled 100% properly *without modification* by
>>> > cygwin-mount.
>>>
>>> IIRC /home is "mounted" from /c/cygwin/home, and cywin-mount has/had
>>> support for such rewriting, tho it may not be enabled by default, or may
>>> not have been updated to work with recent Emacsen/Cygwin.
> Not correct:
> oob2$ mount
> C:/cygwin/bin on /usr/bin type ntfs (binary,noacl)
> C:/cygwin/lib on /usr/lib type ntfs (binary,noacl)
> C:/cygwin on / type ntfs (binary,noacl)
> C: on /c type ntfs (binary,noacl,posix=0,user)
> D: on /d type ntfs (binary,noacl,posix=0,user)
> E: on /e type vfat (binary,noacl,posix=0,user)
> Y: on /cygdrive/y type smbfs (binary,noacl,posix=0,user,noumount,auto)
> Z: on /cygdrive/z type ntfs (binary,noacl,posix=0,user,noumount,auto)
> oob2$
> There is no mount for /home.
But there a mount from c:/cygwin to / so cygwin-mount should be able
to translate /home/user/foo.el to c:/cygwin/home/user/foo.el. At least
in theory.
Stefan