[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: |
layer |
Subject: |
Re: problems with emacsclient started by cygwin programs (mswindows) |
Date: |
Mon, 04 Jul 2011 16:46:18 -0700 |
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