Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Compute table candidates with last buffer current #316

Conversation

clemera
Copy link
Collaborator

@clemera clemera commented Jan 4, 2021

As discussed in #75 and #312 describe-variable was slowed down with Selectrum because the predicate switches back to the last buffer for each candidate. By computing the candidates with the last buffer current by default we avoid the slow down for such cases. The docs don't mention any assumptions about the current buffer for the table/predicate, Ivy does run the computation before the minibuffer is even entered so it doesn't has this problem, we keep computing them late to allow for example selectrum-set-selected-candidate to skip the initial computation which is used by embark for example.

@clemera clemera force-pushed the compute-completion-table-with-last-buffer-current branch from 4abad66 to 2130dea Compare January 4, 2021 14:14
@clemera clemera force-pushed the compute-completion-table-with-last-buffer-current branch 2 times, most recently from d43c098 to fd94186 Compare January 4, 2021 14:18
@clemera clemera force-pushed the compute-completion-table-with-last-buffer-current branch from fd94186 to 7016d80 Compare January 4, 2021 14:31
@clemera clemera changed the title Compute completion table with last buffer current Compute table candidates with last buffer current Jan 4, 2021
@clemera clemera merged commit b462920 into radian-software:master Jan 4, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

1 participant