Re: file-name-shadow-mode

[David Kastrup]

David Kastrup <address@hidden> writes:

> Miles Bader <address@hidden> writes:
>
>> On Mon, 21 Mar 2005 08:24:38 -0500, Stefan Monnier
>> <address@hidden> 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