[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: Sun, 31 Jan 2016 17:02:54 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:44.0) Gecko/20100101 Thunderbird/44.0

On 01/31/2016 09:18 AM, Stefan Monnier wrote:
(defun completing-read-strict (prompt
                                collection &optional predicate
                                hist default inherit-input-method)

I think `default' should come earlier, maybe even before `&optional'.

We can't always provide a non-nil default value (such as in the case of project-find-file), and &optional is a good indicator that the parameters after it are null-able. I'd put DEFAULT after PREDICATE, or right before it.

You can probably get a cleaner behavior if you change
minibuffer-complete-and-exit so that it does most of the new work (but
only when called from completing-read-strict).

That could improve completing-read-default's behavior, but wouldn't help when any other completing-read-function is used. Which was my main concern.

But yes, we can do that (probably on master).

We could check `default' directly when we receive it, but I'd rather not
do that:
- it would ruin efforts to make completion tables more lazy.
- it's rarely useful, but in 99% of the cases, we already know that
   the default is a valid value.
But yes, it should probably be considered "bad karma" for the caller to
provide an invalid `default'.

Right, I already removed the advance checks on DEFAULT from project--completing-read-strict. We could document the "bad karma" consideration, and then the main missing thing would be to show the completions for DEFAULT, or the "no matches" message, right after the user presses RET.

reply via email to

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