|
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.
[Prev in Thread] | Current Thread | [Next in Thread] |