Re: problems with emacsclient started by cygwin programs (mswindows)

[Stefan Monnier]

>>> 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