> 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
_______________________________________________
Emacs-devel mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/emacs-devel
