[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Dmitry Gutov
Subject: Re: make project--find-in-file generic, add interactive filename to project-find-file
Date: Sat, 30 Jan 2016 00:53:35 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:44.0) Gecko/20100101 Thunderbird/44.0

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))
    (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

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]