Re: file-name-shadow-mode

[David Kastrup <dak@gnu.org>]

Stefan Monnier <monnier@iro.umontreal.ca> 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