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: opening /tmp//foo doesn't work. Date: Sun, 13 Nov 2005 16:05:05 -0500 Message-ID: <87acg8p8mz.fsf-monnier+emacs@gnu.org> References: <20051112104720.GK11234@boetes.org> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1131915992 769 80.91.229.2 (13 Nov 2005 21:06:32 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 13 Nov 2005 21:06:32 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Nov 13 22:06:29 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1EbP2k-0007AW-3z for ged-emacs-devel@m.gmane.org; Sun, 13 Nov 2005 22:05:44 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EbP2i-0005Wz-9P for ged-emacs-devel@m.gmane.org; Sun, 13 Nov 2005 16:05:40 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EbP2N-0005QX-7r for emacs-devel@gnu.org; Sun, 13 Nov 2005 16:05:19 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EbP2E-0005MG-Oe for emacs-devel@gnu.org; Sun, 13 Nov 2005 16:05:18 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EbP2E-0005M5-Dr for emacs-devel@gnu.org; Sun, 13 Nov 2005 16:05:10 -0500 Original-Received: from [209.226.175.93] (helo=tomts36-srv.bellnexxia.net) by monty-python.gnu.org with esmtp (Exim 4.34) id 1EbP2D-0006Jb-5F for emacs-devel@gnu.org; Sun, 13 Nov 2005 16:05:09 -0500 Original-Received: from alfajor ([65.92.243.185]) by tomts36-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20051113210505.KDUM16985.tomts36-srv.bellnexxia.net@alfajor>; Sun, 13 Nov 2005 16:05:05 -0500 Original-Received: by alfajor (Postfix, from userid 1000) id A0F6F2FD7E; Sun, 13 Nov 2005 16:05:05 -0500 (EST) Original-To: emacs-devel@gnu.org In-Reply-To: <20051112104720.GK11234@boetes.org> (Han Boetes's message of "Sat, 12 Nov 2005 11:46:58 +0059") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) 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:45896 Archived-At: > So I would like to suggest that if opening /foo fails emacs will > s|//|/|g and then try to open /tmp/foo, and if that fails will > report that /foo and /tmp/foo do not exist. I much prefer M-x file-name-shadow-mode RET The /tmp//foo => /foo translation is (hopefully) only applied on interactively input file names, so all we need is clear feedback about what's going on. BTW, I still have the following patch which makes file-name-shadow-mode work correctly even with funny file-name-handlers and without horrible regexps. Any objections? Stefan Index: rfn-eshadow.el =================================================================== RCS file: /cvsroot/emacs/emacs/lisp/rfn-eshadow.el,v retrieving revision 1.15 diff -u -u -b -r1.15 rfn-eshadow.el --- rfn-eshadow.el 6 Aug 2005 22:13:43 -0000 1.15 +++ rfn-eshadow.el 13 Nov 2005 21:03:59 -0000 @@ -98,7 +98,7 @@ '(face file-name-shadow field shadow) "Properties given to the `shadowed' part of a filename in the minibuffer. Only used when `file-name-shadow-mode' is active. -If emacs is not running under a window system, +If Emacs is not running under a window system, `file-name-shadow-tty-properties' is used instead." :type file-name-shadow-properties-custom-type :group 'minibuffer) @@ -121,20 +121,6 @@ ;;; Internal variables -;; Regexp to locate dividing point between shadow and real pathname -(defconst rfn-eshadow-regexp - (cond ((memq system-type '(ms-dos windows-nt)) - ;; This horrible regexp considers the following patterns as - ;; starting an absolute pathname, when following a `/' or an `\': - ;; L: / // ~ $ \\ \\\\ - "\\(.*[^/]+/+?\\|/*?\\|\\)\\(~\\|$[^$]\\|$\\'\\|[][\\^a-z]:\\|//?\\([^][\\^a-z/$~]\\|[^/$~][^:]\\|[^/$~]?\\'\\)\\)") - (t - ;; default is for unix-style filenames - "\\(.*/\\)\\([/~]\\|$[^$]\\|$\\'\\)")) - "Regular expression used to match shadowed filenames. -There should be at least one regexp group; the end of the first one -is used as the end of the shadowed portion of the filename.") - ;; A list of minibuffers to which we've added a post-command-hook. (defvar rfn-eshadow-frobbed-minibufs nil) @@ -168,31 +154,48 @@ (add-to-list 'rfn-eshadow-frobbed-minibufs (current-buffer)) (add-hook 'post-command-hook #'rfn-eshadow-update-overlay nil t))) +(defsubst rfn-eshadow-sifn-equal (goal pos) + (equal goal (condition-case nil + (substitute-in-file-name + (buffer-substring-no-properties pos (point-max))) + ;; `substitute-in-file-name' can fail on partial input. + (error nil)))) + ;; post-command-hook to update overlay (defun rfn-eshadow-update-overlay () "Update `rfn-eshadow-overlay' to cover shadowed part of minibuffer input. -This is intended to be used as a minibuffer post-command-hook for +This is intended to be used as a minibuffer `post-command-hook' for `file-name-shadow-mode'; the minibuffer should have already been set up by `rfn-eshadow-setup-minibuffer'." - ;; This is not really a correct implementation; it won't always do the - ;; right thing in the presence of environment variables that - ;; substitute-in-file-name would expand; currently it just assumes any - ;; environment variable contains an absolute filename. - (save-excursion - (let ((inhibit-point-motion-hooks t)) - (goto-char (minibuffer-prompt-end)) - ;; Update the overlay (which will evaporate if it's empty). - (move-overlay rfn-eshadow-overlay - (point) - (if (looking-at rfn-eshadow-regexp) - (match-end 1) - (point)))))) - - -;;; Note this definition must be at the end of the file, because -;;; `define-minor-mode' actually calls the mode-function if the -;;; associated variable is non-nil, which requires that all needed -;;; functions be already defined. [This is arguably a bug in d-m-m] + (condition-case nil + (let ((goal (substitute-in-file-name (minibuffer-contents))) + (mid (overlay-end rfn-eshadow-overlay)) + (start (minibuffer-prompt-end)) + (end (point-max))) + (unless + ;; Catch the common case where the shadow does not need to move. + (and mid + (or (eq mid end) + (not (rfn-eshadow-sifn-equal goal (1+ mid)))) + (or (eq mid start) + (rfn-eshadow-sifn-equal goal mid))) + ;; Binary search for the greatest position still equivalent to + ;; the whole. + (while (or (< (1+ start) end) + (if (and (< (1+ end) (point-max)) + (rfn-eshadow-sifn-equal goal (1+ end))) + ;; (SIFN end) != goal, but (SIFN (1+end)) == goal, + ;; We've reached a discontinuity: this can happen + ;; e.g. if `end' point to "/:...". + (setq start (1+ end) end (point-max)))) + (setq mid (/ (+ start end) 2)) + (if (rfn-eshadow-sifn-equal goal mid) + (setq start mid) + (setq end mid))) + (move-overlay rfn-eshadow-overlay (minibuffer-prompt-end) start))) + ;; `substitute-in-file-name' can fail on partial input. + (error nil))) + ;;;###autoload (define-minor-mode file-name-shadow-mode "Toggle File-Name Shadow mode. @@ -220,5 +223,5 @@ (provide 'rfn-eshadow) -;;; arch-tag: dcf70a52-0115-4ec2-b1e3-4f8d3541a888 +;; arch-tag: dcf70a52-0115-4ec2-b1e3-4f8d3541a888 ;;; rfn-eshadow.el ends here