From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: file-name-shadow-mode Date: Mon, 21 Mar 2005 15:05:38 +0100 Message-ID: References: <200503180435.j2I4Z2R18621@raven.dms.auburn.edu> <87is3p5zp2.fsf-monnier+emacs@gnu.org> <200503191521.j2JFL8901509@raven.dms.auburn.edu> <87r7ibziw6.fsf-monnier+emacs@gnu.org> <200503200230.j2K2UvS03067@raven.dms.auburn.edu> <87is3lw2yk.fsf-monnier+emacs@gnu.org> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1111414337 22484 80.91.229.2 (21 Mar 2005 14:12:17 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 21 Mar 2005 14:12:17 +0000 (UTC) Cc: miles@gnu.org, snogglethorpe@gmail.com, teirllm@dms.auburn.edu, rms@gnu.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Mar 21 15:12:16 2005 Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1DDNdU-0004f0-Qn for ged-emacs-devel@m.gmane.org; Mon, 21 Mar 2005 15:12:05 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DDNuM-0002RK-0x for ged-emacs-devel@m.gmane.org; Mon, 21 Mar 2005 09:29:30 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DDNst-0001hL-G0 for emacs-devel@gnu.org; Mon, 21 Mar 2005 09:28:00 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DDNsm-0001d5-KZ for emacs-devel@gnu.org; Mon, 21 Mar 2005 09:27:53 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DDNsj-0001Rj-Lr for emacs-devel@gnu.org; Mon, 21 Mar 2005 09:27:50 -0500 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1DDNXX-00059P-Uj for emacs-devel@gnu.org; Mon, 21 Mar 2005 09:05:56 -0500 Original-Received: from localhost ([127.0.0.1] helo=lola.goethe.zz) by fencepost.gnu.org with esmtp (Exim 4.34) id 1DDNXR-0004k7-0h; Mon, 21 Mar 2005 09:05:49 -0500 Original-To: Stefan Monnier In-Reply-To: <87is3lw2yk.fsf-monnier+emacs@gnu.org> (Stefan Monnier's message of "Mon, 21 Mar 2005 08:24:38 -0500") 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 X-MailScanner-To: ged-emacs-devel@m.gmane.org Xref: news.gmane.org gmane.emacs.devel:34889 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:34889 Stefan Monnier writes: > How 'bout the patch below which makes no assumption (that I know of) > about substitute-in-file-name, and will thus correctly even with > weird magic file name handlers. > + (condition-case nil > + (let ((goal (substitute-in-file-name (minibuffer-contents))) > + (start (minibuffer-prompt-end)) > + (end (point-max))) > + ;; Binary search for the greatest position still equivalent to > + ;; the whole. > + (while (< (1+ start) end) > + (let ((mid (/ (+ start end) 2))) > + (if (equal (condition-case nil > + (substitute-in-file-name > + (buffer-substring mid (point-max))) > + (error nil)) > + goal) > + (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))) Cute. It makes the assumption, however, that there is a unique point where that equivalence occurs. I don't think that this is correct: whenever you split in the middle of an environment variable name, you'll get a nonmatch that can turn into a match if you happen to look further. So it would appear to me that one does not get around either recognizing syntactical entities and skipping them completely instead of partially, or going through the whole expression anyhow. It would appear to me that by far the most robust and also efficient approach would probably be to provide a substitute-in-file-name-partially primitive that would expand everything until the next single non-literal change, returning the relevant information for splicing in the change and continuing the scan. Possibly it might come handy for other file name manipulation tasks. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum