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: rfn-eshadow Date: Tue, 08 Jan 2008 21:17:40 -0500 Message-ID: References: <87k5mq60y8.fsf@jurta.org> <87tzltrjqc.fsf@jurta.org> <87wsqp2r7v.fsf@jurta.org> <87d4shgrgo.fsf@gmx.de> <87fxxclfss.fsf@jurta.org> <87ir27t5ae.fsf@gmx.de> <87sl1apql7.fsf@jurta.org> <87zlviunpk.fsf@gmx.de> <8763y324rn.fsf@jurta.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1199845164 10614 80.91.229.12 (9 Jan 2008 02:19:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 9 Jan 2008 02:19:24 +0000 (UTC) Cc: Michael Albinus , rms@gnu.org, emacs-devel@gnu.org To: Juri Linkov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jan 09 03:19:45 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1JCQXg-0000Yy-Li for ged-emacs-devel@m.gmane.org; Wed, 09 Jan 2008 03:19:44 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JCQXJ-0002nP-8D for ged-emacs-devel@m.gmane.org; Tue, 08 Jan 2008 21:19:21 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JCQVn-0000sR-Gv for emacs-devel@gnu.org; Tue, 08 Jan 2008 21:17:47 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JCQVm-0000rA-Em for emacs-devel@gnu.org; Tue, 08 Jan 2008 21:17:46 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JCQVm-0000qv-5g for emacs-devel@gnu.org; Tue, 08 Jan 2008 21:17:46 -0500 Original-Received: from ironport2-out.pppoe.ca ([206.248.154.182]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JCQVi-00065j-0A; Tue, 08 Jan 2008 21:17:42 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAOK9g0fO+K+E/2dsb2JhbACpa4EB X-IronPort-AV: E=Sophos;i="4.24,259,1196658000"; d="scan'208";a="12444431" Original-Received: from smtp.pppoe.ca ([65.39.196.238]) by ironport2-out.pppoe.ca with ESMTP; 08 Jan 2008 21:17:40 -0500 Original-Received: from pastel.home ([206.248.175.132]) by smtp.pppoe.ca (Internet Mail Server v1.0) with ESMTP id PDA00041; Tue, 08 Jan 2008 21:17:41 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 18B6D8231; Tue, 8 Jan 2008 21:17:40 -0500 (EST) In-Reply-To: <8763y324rn.fsf@jurta.org> (Juri Linkov's message of "Wed, 09 Jan 2008 02:59:08 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.50 (gnu/linux) X-detected-kernel: by monty-python.gnu.org: Genre and OS details not recognized. X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:86614 Archived-At: >>> Thanks, but it now produces weird results, e.g. removing a letter from >>> the beginning of an URL and retyping it again doesn't remove the file name >>> shadow. This is because url-handlers.el is not loaded, and url-file-handler >>> is undefined. I see two variants of fixing this: either by explicitly >>> loading url-handlers.el, or adding an ###autoload cookie to url-file-handler >>> (I think this is better). >> >> I've done the latter. > After your changes arrived to the trunk I observe a strange behavior: > 1. emacs -Q > 2. M-x ffap-bindings RET > 3. C-x C-f C-a C-k / s u : : / C-g > 4. C-h v file-name-handler-alist RET > And `file-name-handler-alist' doesn't contain `tramp-file-name-handler' > anymore. But in the Emacs 22 branch everything is correct. > Do you see the same? Indeed, in the above recipe, Tramp gets loaded while we're inside the ffap, i.e. while inside the `let' binding, so the tramp-file-name-handler' gets removed when get out of the let binding :-( I.e. we shouldn't use let-binding. I installed the untested patch below which should hopefully fix this problem. Stefan --- ffap.el.~1.68.~ 2008-01-08 21:08:40.000000000 -0500 +++ ffap.el 2008-01-08 21:13:19.000000000 -0500 @@ -1263,10 +1263,10 @@ (setq dir (file-name-directory guess)))) (let ((minibuffer-completing-file-name t) (completion-ignore-case read-file-name-completion-ignore-case) - ;; because of `rfn-eshadow-update-overlay'. - (file-name-handler-alist - (cons (cons ffap-url-regexp 'url-file-handler) - file-name-handler-alist))) + (fnh-elem (cons ffap-url-regexp 'url-file-handler))) + ;; Explain to `rfn-eshadow' that we can use URLs here. + (push fnh-elem file-name-handler-alist) + (unwind-protect (setq guess (completing-read prompt @@ -1276,7 +1276,12 @@ (if dir (cons guess (length dir)) guess) (list 'file-name-history) (and buffer-file-name - (abbreviate-file-name buffer-file-name))))) + (abbreviate-file-name buffer-file-name)))) + ;; Remove the special handler manually. We used to just let-bind + ;; file-name-handler-alist to preserve its value, but that caused + ;; other modifications to be lost (e.g. when Tramp gets loaded + ;; during the completing-read call). + (setq file-name-handler-alist (delq fnh-elem file-name-handler-alist)))) ;; Do file substitution like (interactive "F"), suggested by MCOOK. (or (ffap-url-p guess) (setq guess (substitute-in-file-name guess))) ;; Should not do it on url's, where $ is a common (VMS?) character.