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

Closed
dsedivec opened this Issue May 16, 2016 · 2 comments

Comments

Projects
None yet
2 participants
@dsedivec
Contributor

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, todo.org and todo.org_archive.
  2. Switch to todo.org.
  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: todo.org is first in Ivy's candidates list and is selected, since that was the most recent buffer with that string.

Observed behavior: todo.org 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!

@manuel-uberti

This comment has been minimized.

Contributor

manuel-uberti commented May 17, 2016

I think it is related to this: #496

@dsedivec

This comment has been minimized.

Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment