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 16:47:17 +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 1111420523 13555 80.91.229.2 (21 Mar 2005 15:55:23 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 21 Mar 2005 15:55:23 +0000 (UTC) Cc: miles@gnu.org, teirllm@dms.auburn.edu, Stefan Monnier , rms@gnu.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Mar 21 16:55:22 2005 Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1DDP6a-0002Qy-Gl for ged-emacs-devel@m.gmane.org; Mon, 21 Mar 2005 16:46:13 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DDPNh-0005bg-7W for ged-emacs-devel@m.gmane.org; Mon, 21 Mar 2005 11:03:53 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DDPNQ-0005aB-Ub for emacs-devel@gnu.org; Mon, 21 Mar 2005 11:03:37 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DDPNO-0005YG-4f for emacs-devel@gnu.org; Mon, 21 Mar 2005 11:03:34 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DDPNO-0005YA-2q for emacs-devel@gnu.org; Mon, 21 Mar 2005 11:03:34 -0500 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1DDP7v-0004ex-35 for emacs-devel@gnu.org; Mon, 21 Mar 2005 10:47:35 -0500 Original-Received: from localhost ([127.0.0.1] helo=lola.goethe.zz) by fencepost.gnu.org with esmtp (Exim 4.34) id 1DDP7n-0007jU-S0; Mon, 21 Mar 2005 10:47:28 -0500 Original-To: snogglethorpe@gmail.com In-Reply-To: (David Kastrup's message of "Mon, 21 Mar 2005 16:14:57 +0100") 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:34894 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:34894 David Kastrup writes: > Miles Bader writes: > >> On Mon, 21 Mar 2005 08:24:38 -0500, Stefan Monnier >> wrote: >>> 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. >> >> Um, I should note that the original code was designed to be fast and >> not cons unnecessarily, because it runs on every keystroke -- that's >> the reason it uses just a regexp match and a move-overlay. Your >> suggested replacement looks ... less careful. > > substitute-in-file-name is a built-in function in `C source code'. > (substitute-in-file-name FILENAME &optional PARSEINFO) > > Substitute environment variables referred to in FILENAME. > `$FOO' where FOO is an environment variable name means to substitute > the value of that variable. The variable name should be terminated > with a character not a letter, digit or underscore; otherwise, enclose > the entire variable name in braces. > If `/~' appears, all of FILENAME through that `/' is discarded. > > On VMS, `$' substitution is not done; this function does little and only > duplicates what `expand-file-name' does. > > If PARSEINFO is not NIL, it is a list used or reused for storing > parsing information (it is extended as necessary). > > Elements 2N point to positions in the original string, Elements 2N+1 > to corresponding positions in the substituted string. Add to that: if the source element does not have a corresponding position in the output (i.e., because a later element reintroduces an absolute path element), the corresponding element 2N+1 is nil. > [...] Now we can just do (let ((shadowlist (list nil)) p shadowpos) [start some input loop, inside have:] (substitute-in-filename filename shadowlist) (setq p shadowlist shadowpos 0) (while (setq p (memq nil p)) (setq shadowpos (car (setq p (cdr p))))) > No consing done except when the syntax changes on entry. This holds the same. Is the proposed data structure unnecessary complicated (as in "nobody will ever need that") or too simple (as in "it requires extra work to check that a given source piece is verbatim in the output)? Should there be a possibility to actually reuse already scanned strings in case that only stuff gets appended at the end? -- David Kastrup, Kriemhildstr. 15, 44793 Bochum