Re: make project--find-in-file generic, add interactive filename to project-find-file

[Dmitry Gutov]

On 01/29/2016 05:05 PM, Stefan Monnier wrote:

> What problems do you foresee?

The usual lack of imagination?

With your generous encouragement, I wrote this:

(defun completing-read-strict (prompt
                               collection &optional predicate
                               hist default inherit-input-method)
  (let* ((new-prompt (if default
                         (format "%s (default %s): " prompt default)
                       (format "%s: " prompt)))
         (res (completing-read new-prompt
                               collection predicate t
                               nil hist default inherit-input-method))
         try)
    (if (and (equal res default)
             (not (test-completion res collection predicate))
             (not (and (setq try (car (completion-try-completion
                                       res collection predicate (length 
res))))
                       (setq res try)
                       (test-completion res collection predicate))))
        (completing-read (format "%s: " prompt)
                         collection predicate t res hist nil
                         inherit-input-method)
      res)))

I can use it in completing-read-strict to satisfy both points mentioned 
previously. But after trying it out, I'm not sure about the general 
applicability of the DEFAULT semantics here. It just seems awkward:

First, you tell the user that the default is so-and-so. But if they 
choose to trust you (and aren't even surprised that the default isn't a 
proper absolute filename), in the event that the default does not 
correspond to a particular filename, you drop them into the same prompt 
once again, but without the "default" part. And now the input contains 
either:

- The previous "default" which has _some_ matches, and the user has to 
figure that out, because I can't force the completing-read-function to 
show the matches right away (the default one doesn't, it waits for me to 
press TAB or RET; it's easier with icomplete-mode on).

- The previous "default" input which has no matches. The user doesn't 
know about that right away either, so they must feel disoriented in this 
case too. Seeing (no matches) at this step would be better.

- Nothing. Which could make sense if the previous "default" didn't 
actually match anything, but the user must be even more surprised in 
this case ("where did my default go?").

We could filter out the last two cases before calling 
completing-read-strict, and don't pass DEFAULT in at all then, but this 
makes the new function less necessary, and the first case remains confusing.

And as long as completing-read-strict, by itself, does allow the case of 
"default that doesn't match anything", that makes me doubt its semantics.