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

[layer]

Stefan Monnier wrote:

>> >>> > OK, changes below for my proposed hook.  Comments welcome.
>> >>> > If I've not submitted this correctly and there's a FAQ about
>> >>> > submitting, please point me to it and I'll gladly do it some other
>> >>> > way.
>> >>> I don't know Windows well enough to know exactly what should happen, but
>> >>> here are some thoughts:
>> >>> - you can solve your problem with something like cywin-mount.el.
>> >>> I know Eli doesn't like cywin-mount.el, but I think we should at least
>> >>> add such a feature to GNU ELPA.
>> > I use cygwin-mount.el and it doesn't solve the problem.  The reason:
>> > expand-file-name was creating invalid pathnames (c:/home/... rather
>> > than c:/cygwin/home/...).  cygwin-mount.el is for rewriting *valid*
>> > pathnames.
>> 
>> 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.

>> >>> - It might still make sense to want to understand cygwin-style file
>> >>> names from emacsclient without wanting cygwin-mount (which tries to
>> >>> handle cywin file names *everywhere*).  But then it should probably
>> >>> work not only for emacsclient but also for file name args to emacs
>> >>> itself (as a general rule, we should strive to make `emacs' and
>> >>> `emacsclient' command line handling more similar rather than more
>> >>> different).
>> > The problem I'm trying to solve is unique to a cygwin program
>> > calling emacsclient.  I'm not sure we want to generalize it beyond
>> > that.
>> 
>> 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.)

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

I'm not wedded to my solution.  If there's a cygwin-mount-based
solution, I'm OK with it.  However, I just don't see it.

cygwin-mount seems to work fine with 23.2, btw.

Kevin