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

[layer]

Stefan, I appreciate you hashing this out with me.  More below.

Stefan Monnier wrote:

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

I think the current return value is the only sane one.  My point was
only that the pathname was invalid outside of cygwin.

>> 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 mostly agree.  The problem only happens when external pathnames get
introduced into emacs.  The ways this can happen are:

 - command line
 - server (used by emacsclient)

I'm not sure they can get into emacs in other meaningful ways.

Continuing my thoughts at the end...

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

I see now what you mean, and I agree it would be the same problem.

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

But when it's OK to do this?  What if there was a c:/home/ and
c:/cygwin/home, then what would /home refer to?  Could be c:/home/ and
not c:/cygwin/home/.

To me, this global interpretation of pathnames (if I correctly
interpret what you are suggesting for expand-file-name or
cygwin-mount) to fix them is asking for trouble.  On the other hand, I
know the emacs command line and emacs server inputs will for me always
have cygwin paths on them.

If, however, I was using the cygwin-built emacs, none of what we've
been discussing would be needed.  That's why I think it's best in a
hook.

I do (now) agree that hook should be applied to the command line
processing.  If we come to agreement on all this I can look into doing
that, too.

Kevin