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

ivy-switch-buffer prefers special buffers #522

Closed
benmaughan opened this issue May 25, 2016 · 3 comments
Closed

ivy-switch-buffer prefers special buffers #522

benmaughan opened this issue May 25, 2016 · 3 comments

Comments

@benmaughan
Copy link

benmaughan commented May 25, 2016

Hi,
First, thanks for the great software!
I see some unexpected (to me) behaviour in ivy-switch-buffer. Say I have two buffers called

 out.txt
 *Shell Command Output*

and I start ivy-switch-buffers and type "out" then the *Shell Command Output* buffer is highlighted and I have to continue typing or use the arrows to select out.txt. I would have expected out.txt to be the preferred match since the string is at the start of the buffer name. I realise I could type "^out" to match out.txt but I would have expected the priority of the results to be different. This seems to be the case whenever there is a *special* buffer that matches the search string anywhere in the name.

Is this the intended behaviour?

Cheers,
Ben

@ardpp
Copy link

ardpp commented May 25, 2016

This is the expected behaviour as far as I know. See if #513 and #496 answer your question.

Andrej

@abo-abo
Copy link
Owner

abo-abo commented May 25, 2016

This is a bug related to the fact that ivy-switch-buffer starts with candidate index 1 instead of the usual index 0. This is to enable the quick last buffer cycle with RET. This behavior is compatible with Emacs defaults and isn't going away.

However, this reveals that bug in the anchoring algorithm. The anchoring algorithm recomputes the candidate index with updates in the input. It tries to make it so the closest matching candidate below the previous one is selected. This fix isn't trivial, and I don't have enough time to fix it properly right now. So this issue and the mentioned ones will have to stay open for a while.

The simplest way to fix it is to reset the index to 0 with each input, however it's a lazy solution and I'd rather have the proper one.

@benmaughan
Copy link
Author

Thanks for clarifying.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants