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: A few Windows build fixes Date: Wed, 07 Sep 2011 08:50:37 -0400 Message-ID: References: <83vcth40ik.fsf@kalahari.s2.org> <83r5444ome.fsf@kalahari.s2.org> <87pqjmfgia.fsf@gmail.com> <8739ggf8ph.fsf@gmail.com> <8262lbu7g5.fsf@gmail.com> <83y5y7cthv.fsf@gnu.org> <83ty8vt4y8.fsf@gnu.org> <83obz2uc11.fsf@gnu.org> <83aaahjzmh.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1315399860 2880 80.91.229.12 (7 Sep 2011 12:51:00 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 7 Sep 2011 12:51:00 +0000 (UTC) Cc: andrewjmoreton@gmail.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Sep 07 14:50:54 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 1R1Hag-0000r5-1S for ged-emacs-devel@m.gmane.org; Wed, 07 Sep 2011 14:50:54 +0200 Original-Received: from localhost ([::1]:58332 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R1Hae-0000m5-MI for ged-emacs-devel@m.gmane.org; Wed, 07 Sep 2011 08:50:52 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:42047) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R1HaW-0000li-Ey for emacs-devel@gnu.org; Wed, 07 Sep 2011 08:50:49 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R1HaV-0005vX-6n for emacs-devel@gnu.org; Wed, 07 Sep 2011 08:50:44 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.183]:4528 helo=ironport2-out.pppoe.ca) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R1HaQ-0005ut-Uc; Wed, 07 Sep 2011 08:50:38 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EACNoZ064rwMJ/2dsb2JhbABDp2l5gUYBAQQBViMFCws0EhQYDRABE4gIt2+GawSgI4RA X-IronPort-AV: E=Sophos;i="4.68,345,1312171200"; d="scan'208";a="134939113" Original-Received: from 184-175-3-9.dsl.teksavvy.com (HELO ceviche.home) ([184.175.3.9]) by ironport2-out.pppoe.ca with ESMTP/TLS/ADH-AES256-SHA; 07 Sep 2011 08:50:37 -0400 Original-Received: by ceviche.home (Postfix, from userid 20848) id 9314D66246; Wed, 7 Sep 2011 08:50:37 -0400 (EDT) In-Reply-To: (Eli Zaretskii's message of "Wed, 07 Sep 2011 01:17:56 -0400") 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:143793 Archived-At: >> >> We'd want it to have zero impact to the users who don't use cygwin >> >> (and may not even have it installed), of course. >> > They will never see such file names. >> That can be argued (all file names starting with "/" are potential >> Cygwin names). > I was talking about /cygdrive/x/ file names that should be translated > to x:/ and vice versa. This must be on the C level, AFAIU. For me, the convincing argument to add a "convert-external-file-name" function to use on command-line args and such was specifically to be able to handle *all* forms of Cygwin file names, including the ones that are ambiguous (/home/foo was one motivating example, if I remember). This was brought up in a feature-request for emacsclient arguments. > The "mounted" file names, if we want or need to support them, will > have to be looked up in the mount list taken from "mount -m". FWIW, in that example, the mount point was "/some/where is mounted on /" (and as it turns out the "mounted on /" is a case not handled by cygwin-mount.el). So /home/foo really meant /some/where/home/foo, but to figure that out, we'd first have to decide whether to interpret /home/foo as a Cygwin name or as a native name. > I don't see how the fact that Cygwin is or isn't installed is related > to implementing the translation, except that "mount -m" will fail if [...] > Loading the Cygwin DLL into a native w32 process is impossible, so > that's not an option. I see, so indeed, Cygwin's availability is irrelevant since we won't use the Cygwin DLL anyway. >> I thought we still had problems delivering signals to them. > You are right, we don't support sending Posix signals to Cygwin > programs. But where is that a real problem? Emacs does know how to > interrupt a subprocess, and the way it does that should work with > Cygwin programs as well, albeit with less flexibility. After all, > Cygwin programs are just specialized Windows applications. It is a cause of problems for the SSL/TLS support (when we use gnutls-cli rather than the gnutls DLL), for example. Stefan