Stefan Monnier <[EMAIL PROTECTED]> 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 _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
