Re: file-name-shadow-mode

[Stefan Monnier]

> Cute.  It makes the assumption, however, that there is a unique point
> where that equivalence occurs.

Not quite, it makes the assumption that if

   (substitute-in-file-name (buffer-substring N END))
   == (substitute-in-file-name (buffer-substring START END))

and (< START N) then

   (substitute-in-file-name (buffer-substring (1- N) END))
   == (substitute-in-file-name (buffer-substring START END))

This assumption is inded not always verified.  But the only counter-example
I can think of is with the "/:" oddity that I mentioned in another message
(a similar one occurs with http://).  I was thinking of adding a check to
eliminate those very special cases.

In any case, the good side of my patch is that even if doesn't do quite what
you want, it guarantees that `substitute-in-file-name' returns the same
thing when passed the whole minibuffer's content or just the
non-shadowed part.  I.e. it never gives a *wrong* result.

> 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.

Hmmm.... could you explain what concrete case you have in mind?


        Stefan