Consult narrowing is broken due to computing table outside minibuffer

[minad]

The offending commit is b462920, found via bisect. It worked before that commit and it still works with icomplete. Some problem with the predicate. My suggestion would be to revert b462920 at first.

[minad]

Okay now I understand the problem - my predicate relies on being executed in the minibuffer :(

And this works with icomplete so I wonder what the correct behavior is.

[clemera]

The commit was to speed up for describe-variable, why does narrowing need the minibuffer buffer to be current?

[minad]

@clemera It relies on minibuffer local variables.

EDIT: I could also fix this on the side of consult trying to obtain the minibuffer local variable. But I think we should figure out instead what the correct behavior is. Maybe really special case describe variable? I mean introducing a buffer switch is not natural, so it is unexpected that this happens by default. For describe-variable we need the special case though. What is ivy doing exactly? Are they also doing exactly this - switching to the latest buffer?

EDIT2: I think the natural thing is that all the callbacks invoked from completing-read live inside the minibuffer. I think this is what I implicitly assumed all the time and I think this assumption did hold until now. Also for the annotators I think.

[clemera]

I agree the buffer switch can always be unexpected. Ivy does compute the candidates before even entering the minibuffer. In the light of this I think special casing is probably the best here.

[minad]

Maybe it makes sense to special case the exact predicate function. I guess it is a named predicate for describe-variable, not a lambda?

[clemera]

No, it is a lambda I think we can do it for #'help--symbol-completion-table

[minad]

@clemera Okay, that's also good!

[clemera]

The other commands that use it are describe-function and describe-symbol and they do no buffer switching so they aren't affected by this

[clemera]

Can be closed?