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

Selecting the second buffer after filtering in ivy-switch-buffer leads to unintuitive buffer switching #513

dsedivec opened this issue May 16, 2016 · 2 comments


Copy link

@dsedivec dsedivec commented May 16, 2016

Steps to reproduce, using ivy-switch-buffer to switch buffers:

  1. Open two buffers with a common prefix. In my case, and todo.org_archive.
  2. Switch to
  3. Switch to some third buffer, like *Messages*.
  4. Switch to some fourth buffer, like *scratch*.
  5. Invoke ivy-switch-buffer.
  6. Start typing your common prefix from step 1, e.g. todo.

Expected behavior: is first in Ivy's candidates list and is selected, since that was the most recent buffer with that string.

Observed behavior: is first in Ivy's candidates, but todo.org_archive is the second and is the selected option, presumably because ivy-switch-buffer starts with the "other" buffer selected by default, which (AFAIK) is always the second option.

Is there any way to get ivy-switch-buffer to select the most recent non-current buffer after filtering? I believe this behavior changed as of 79ffa67 (#484). Thanks!

Copy link

@manuel-uberti manuel-uberti commented May 17, 2016

I think it is related to this: #496

Copy link
Contributor Author

@dsedivec dsedivec commented Jun 17, 2016

In an effort to scratch my own itch here, I've replaced use of ivy--old-cands in ivy--recompute-index with ivy--current. That bit of code seems to exist to keep the current candidate selected if it's still a candidate, but ivy--old-cands is now updated before ivy--recompute-index is called, so that (nth) form no longer returns the current candidate, potentially. Or, at least, that's my hypothesis based on my very limited understanding of ivy.el.

So far it seems good but I'm going to run with this for a while to see if this fixes my issue without breaking anything else.

@abo-abo abo-abo closed this in c84b681 Jul 29, 2016
abo-abo added a commit that referenced this issue Aug 16, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants