Add a simple initial counsel-switch-buffer #1895
I was thinking about that too, but I always felt this way: ivy is a general framework for a better completing-read. Counsel has all the task specific commands (how to awesomely browse files, functions, variables and now buffers). If later we have more and more ideas to make this initial implementation better, than that would fit right into counsel, but would feel awkward in ivy.
This is why I have put the new feature into counsel.
Another reason, which I think is quite important: there are already many users and this is a change, which can be upsetting for people. E.g. if you don't like huge part of the screen changing when you are not focusing there with your eye. Or you work on a slow X connection or terminal. If we put this into counsel, then ivy-switch-buffer doesn't have to change, we need no confusing customization values with debatable defaults and the like.
I would be happy to hear your opinions too, if you don't mind!
@Alexander-Shukaev I tested that for a while and then decided to remove it.
There are a lot of corner cases to work out with the kill functionality of that keymap. And if I saw it correctly, there is no other keys in it, only the killing.
I would prefer to handle all that strangeness and bug hunting in a second PR if we decide to.
Would it make sense for documentation purposes to do the following: have a company-switch-buffer-map, which is a copy-keymap of the ivy one, but then undefining the killing in that with the comment that it's too buggy with the preview. Then whenever in the future new keys are added to ivy, we will have those and also people will understand that it's a good project to work on the kinks of the killing functionality.
@mookid The PR handles them in the sense that they don't confuse the PR. So they are ignored and won't cause problems. Proper support I think would need further work and some decisions, for which I would like to know @abo-abo's opinion. E.g. do we kill the files that we have opened just for preview or do we only bury them? Do we really open every file which is randomly focused during typing or do we have a delay? What is the default value for the delay?
So I'm happy to work on these, but would like to have small PRs one-by-one, if that's OK with the community.
If you do some initial work towards this on top of my PR, I would be very-very happy to take a look and give it a test-drive!
What visual studio does in that kind of scenario is quite acceptable: open the buffer for preview, and kill it if it is not selected.
It may be possible. If i have something concrete to show, I'll let you know :)
Thanks. I like the functionality.
Do you have an Emacs Copyright Assignment?
I notice quite a bit of code repetition between
Here's how it could work:
(add-to-list 'ivy-update-fn-alist '((ivy-switch-buffer . counsel--switch-buffer-update-fn)))
And it would be useful elsewhere. For instance, by default
We could do:
(add-to-list 'ivy-update-fn-alist '((counsel-ag . (lambda () (with-ivy-window (counsel-git-grep-action (ivy-state-current ivy-last)))))))
@abo-abo I will look into your technical comments and reply soon.
About the copyright assignment: I have it for ages, since 10 years or something. Do you need some kind of proof? Because then I have to look into it. What do you need, some kind of ticket number or a PDF?
* ivy.el (ivy-unwind-fns-alist): New defvar. Reduce code duplication by having `counsel-switch-buffer' become a customized `ivy-switch-buffer'. Re #1895
* ivy.el (ivy-unwind-fns-alist): New defvar. Reduce code duplication by having `counsel-switch-buffer' become a customized `ivy-switch-buffer'. Re abo-abo#1895