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: substitute-in-file-name is not distributive Date: Tue, 30 Oct 2012 14:58:18 -0400 Message-ID: References: <50750955.4020802@dancol.org> <5088B1F4.90302@dancol.org> <508F5319.4090604@dancol.org> <508FEBD8.8090505@dancol.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1351623511 11426 80.91.229.3 (30 Oct 2012 18:58:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 30 Oct 2012 18:58:31 +0000 (UTC) Cc: Emacs development discussions To: Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Oct 30 19:58:40 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1TTH1I-0000gu-Hz for ged-emacs-devel@m.gmane.org; Tue, 30 Oct 2012 19:58:36 +0100 Original-Received: from localhost ([::1]:43963 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TTH1A-00058l-BT for ged-emacs-devel@m.gmane.org; Tue, 30 Oct 2012 14:58:28 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:52251) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TTH17-00056a-0Z for emacs-devel@gnu.org; Tue, 30 Oct 2012 14:58:26 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TTH12-0005RE-Qa for emacs-devel@gnu.org; Tue, 30 Oct 2012 14:58:24 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.182]:41622) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TTH12-0005R7-L5 for emacs-devel@gnu.org; Tue, 30 Oct 2012 14:58:20 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAG6Zu0/O+LET/2dsb2JhbABEtBGBCIIVAQEEAVYcBwULCw4mEhQYDRABE4gcBboJhWWFN4UoA6MzgViDBYE7 X-IronPort-AV: E=Sophos;i="4.75,637,1330923600"; d="scan'208";a="203172281" Original-Received: from 206-248-177-19.dsl.teksavvy.com (HELO pastel.home) ([206.248.177.19]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 30 Oct 2012 14:58:19 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id CBB3E59419; Tue, 30 Oct 2012 14:58:18 -0400 (EDT) In-Reply-To: <508FEBD8.8090505@dancol.org> (Daniel Colascione's message of "Tue, 30 Oct 2012 08:01:44 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.182 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:154591 Archived-At: >> Hmm... that's odd. Can you give me some details: >> - tell me exactly which text you typed in the minibuffer. > I typed "c:\bin\" in the minibuffer and hit tab. After hitting tab, the > minibuffer contained "c:/usr/bin", with point at the end. >> - also tell me how the rfn-eshadow highlights the file name at each step. > Now that you mention it, I do see that the leading "c:" in the > minibuffer is highlighted. That explains why we're substituting > "c:/usr/bin" and not "/usr/bin". Right. The "c:" is highlighted because (s-i-f-n "c:\\bin") = (s-i-f-n "\\bin"). Now the problem is that when you replace \bin by /usr/bin suddenly that same rule doesn't apply any more. Hmm... I think the core of the problem here is that minibuffer completion is actually only performed on "the current field" which is usually the whole minibuffer content, but not with rfn-eshadow. To fix this, we should invert the relationship between minibuffer-complete and completion-in-region (i.e. minibuffer-complete should call completion-in-region rather than the other way around). This would probably be a good change, but we can't do it for 24.3. You should be able to work around this problem by removing "field shadow" from file-name-shadow-properties. >> Right. BTW I'm not convinced this is the right pattern to use for your >> file-name-handler. I think catching "\\[a-zA-Z]:" or something along >> these lines might be a better choice. > Not all paths I want to catch are absolute, Why not? Which non-absolute file names [we only use "path" for lists of directories, as in $INFOPATH] would you need/want to rewrite? Do you just want to replace \ with / in relative file names or is there more to it? > Even "absolute" paths can be drive-letter-relative and begin with > a simple backslash. Right, that's what triggers the above problem. >> BTW, does Cygwin allow backslashes in file-names or does it interpret it >> as a separator, like Windows does? > Cygwin interprets backslashes as separators. So Cygin itself treats "\\bin" and "/bin" as equivalent, but your rewrite rules treat "\\bin" as a Windows file name and rewrite it to "/usr/bin"? If you limit yourself to: - rewrite "\\`[a-zA-Z]:" to "/cygdrive/c" (regardless if it is followed by backslashes or forwardslashes). - rewrite \ to / everywhere. This should cover the main needs without tripping over the above problem. Stefan