Closed MonsieurPi closed 3 years ago
why a function expecting 3 arguments is sad about receiving 3 arguments
The error is about a function of 1 argument receiving 3 arguments, and the function in question is counsel-spotify-search-by
, judging by the argument called search-term
.
I don't know whether commit 71c59aecf669142ebe264fac8ff7b440c0c71712 is always TRT, but the above suggests that the problem may lie with counsel-spotify
as well.
Perhaps there is a mixup between normal programmed completion functions which take three arguments (see try-completion
), dynamic completion table transducers which take a single argument (see completion-table-dynamic
), and Ivy :dynamic-collection
completion functions, which also take a single argument (but I don't know whether they work the same as completion-table-dynamic
).
This is a regression caused by that commit, which caused an lsp-ivy
issue: emacs-lsp/lsp-ivy#27. The collection of ivy-read
, if it is a :dynamic-collection
, is not a completion table (because it takes only one argument). The changes need to guard against :dynamic-collection
and only do the completion-table thing if ivy was not called with that.
Something like
;; `:dynamic-collection` COLLECTIONS are not completion tables
(unless (ivy-state-dynamic-collection ivy-last)
(completion-metadata "" minibuffer-completion-table minibuffer-completion-predicate))
fixes this for me.
Workaround:
(defun ivy-update-candidates-dynamic-collection-workaround-a (old-fun &rest args)
(cl-letf (((symbol-function #'completion-metadata) #'ignore))
(apply old-fun args)))
(advice-add #'ivy-update-candidates :around #'ivy-update-candidates-dynamic-collection-workaround-a)
Thanks for the info.
The collection of
ivy-read
, if it is a:dynamic-collection
, is not a completion table (because it takes only one argument).
Then how do you explain that other :dynamic-collection
commands like counsel-git-grep
and counsel-locate
still work?
And why are all these external packages using the undocumented function ivy-update-candidates
?
What am I missing? Paging @abo-abo.
@basil-conto Their collections aren't completion tables either. They work because apparently no other parts of ivy (besides ivy-update-candidates
) wants to use a :dynamic-collection
as a completion table.
As for the other packages, I can only speak for lsp-ivy
: lsp-ivy-workspace-symbol
, which uses ivy-update-candidates
, searches all project symbols, of which there can be many. This is why the LSP protocol allows clients to filter symbols by regex, so we utilize that.
As for the other packages, I can only speak for
lsp-ivy
:lsp-ivy-workspace-symbol
, which usesivy-update-candidates
, searches all project symbols, of which there can be many. This is why the LSP protocol allows clients to filter symbols by regex, so we utilize that.
How does that translate to a need to call ivy-update-candidates
directly?
Anyway, I'll revert the offending commit for now until @abo-abo or someone else comes up with a better solution.
@basil-conto Oh I forgot to mention that. We do the requests asynchrnously. So the user types something, the COLLECTION gets called with the new input, we make a JSONRpc request (not hanging Emacs), and, when the server eventually answers, we just call ivy-update-candidates
to replace the existing ones.
Oh I forgot to mention that. We do the requests asynchrnously. So the user types something, the COLLECTION gets called with the new input, we make a JSONRpc request (not hanging Emacs), and, when the server eventually answers, we just call
ivy-update-candidates
to replace the existing ones.
Thanks, I'm starting to get déjà vu from all the other issues pertaining to external packages using the ad-hoc and undocumented ivy-update-candidates
;).
I've gone with @nbfalcon's suggestion to check for dynamic collections in ivy-update-candidates
, so hopefully that should plug this hole for now. Thanks again.
I installed counsel-spotify and got a
wrong number of arguments
error.I toggled error display and got the following output:
The following commit introduced a call to
(completion-metadata "" minibuffer-completion-table minibuffer-completion-predicate)))
. If I redefine this function like it was before I don't have any error but my elisp-fu is not good enough to understand why a function expecting 3 arguments is sad about receiving 3 arguments