From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: problems with emacsclient started by cygwin programs (mswindows) Date: Mon, 04 Jul 2011 11:15:37 -0400 Message-ID: References: <3326.1309207437@relay.known.net> <30470.1309532436@relay.known.net> <10690.1309544818@relay.known.net> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1309793948 6551 80.91.229.12 (4 Jul 2011 15:39:08 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 4 Jul 2011 15:39:08 +0000 (UTC) Cc: emacs-devel@gnu.org To: layer Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jul 04 17:39:04 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QdlEl-0006b3-P6 for ged-emacs-devel@m.gmane.org; Mon, 04 Jul 2011 17:39:04 +0200 Original-Received: from localhost ([::1]:60574 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QdlEk-0006RV-Ak for ged-emacs-devel@m.gmane.org; Mon, 04 Jul 2011 11:39:02 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:57361) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qdks9-0000Go-Rh for emacs-devel@gnu.org; Mon, 04 Jul 2011 11:15:43 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qdks7-00070W-Oz for emacs-devel@gnu.org; Mon, 04 Jul 2011 11:15:41 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.183]:37486 helo=ironport2-out.pppoe.ca) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qdks7-00070L-4e for emacs-devel@gnu.org; Mon, 04 Jul 2011 11:15:39 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAFLYEU5FxIxr/2dsb2JhbABTp3x4iHrBEoY2BJ5chCw X-IronPort-AV: E=Sophos;i="4.65,472,1304308800"; d="scan'208";a="120372334" Original-Received: from 69-196-140-107.dsl.teksavvy.com (HELO pastel.home) ([69.196.140.107]) by ironport2-out.pppoe.ca with ESMTP/TLS/ADH-AES256-SHA; 04 Jul 2011 11:15:37 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 4C05559173; Mon, 4 Jul 2011 11:15:37 -0400 (EDT) In-Reply-To: <10690.1309544818@relay.known.net> (layer@known.net's message of "Fri, 01 Jul 2011 11:26:58 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.183 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:141531 Archived-At: >>> 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