Selection of first match after changes to the input doesn't always work

[tsdh]

After 126158d, the first match should be selected after the input has changed with the exception of swiper. It works in the case I constructed in #231 but not always. Here's a test case which currently fails:

(should (equal
         (ivy-with '(ivy-read "pattern: " '("aba"
                        "baa"
                        "abc"))
                   "a b <down> <backspace> C-m")
         "aba")) ;; What's actually selected now is baa

Here I'd expect the first item "aba" to be selected because the first matching element should be selected after changes to the input. What's actually selected is "baa" which is neither the first match nor the last match so completely implausible. So that's a bug but I also have two other points.

1. I agree with @PythonNut's comment in Ivy: default input should not stick after typing #231 in that one might want to customize that behavior on a per-command basis. Right now swiper and counsel-git-grep are exceptions identified by the last state having the unwind function swiper--cleanup, but testing for some specific unwind function seems to be the wrong thing to do. So I suggest to introduce some defcustom ivy-select-first-after-change-list (I'm not convinced of the name) and then changing the test to (memq this-command ivy-select-first-after-change-list).
2. I think that once a user switched candidates explicitly with C-n/C-p/<up>/<down>, the selection of the first candidate after changes should be disabled, i.e., the selection should stick to the last one in case it is still valid. If that were implemented, the test case above should expect "abc" instead of "aba".

[PythonNut]

I think that once a user switched candidates explicitly with C-n/C-p//, the selection of the first candidate after changes should be disabled, i.e., the selection should stick to the last one in case it is still valid. If that were implemented, the test case above should expect "abc" instead of "aba".

What would you propose doing if the previously selected candidate no longer matched the new input? Something like:

(should (equal
         (ivy-with '(ivy-read "pattern: " '("aba"
                        "baa"
                        "abc"))
                   "a C-n C-n b C-m ")
         "???")) ;; What should this be?

[tsdh]

If the last one isn't valid anymore, then select the first one again, I.e., aba.

[abo-abo]

@tsdh
The test that you mention was failing because of a typo (ivy-index instead of ivy--index).

(memq this-command ivy-select-first-after-change-list)

I'd like try to avoid this approach in the future. It removes the flexibility of user commands calling ivy functions, and also ivy-resume. When the collection is a list of strings (like swiper works currently), it's hard to uniquely identify it. Maybe some wrapper could be added, similar to avy-with, that would let each command pass its own name to ivy-read. What do you think? Is there a better approach for ivy-read to uniquely identify its collection type? So far, this is my best idea:

(ivy-read
 "Swiper: "
 candidates
 :initial-input initial-input
 :keymap swiper-map
 :preselect preselect
 :require-match t
 :update-fn #'swiper--update-input-ivy
 :unwind #'swiper--cleanup
 :re-builder #'swiper--re-builder
 :history 'swiper-history
 :caller 'swiper)

This would mean that each ivy-read would have to be updated with :caller eventually. But then all ...-alist type customizations would dispatch on :caller instead of this-command.

[tsdh]

Yes, I've also thought about extending the ivy state with a field for the caller, so we may assume that if two people think the same individually, it can't be too wrong.

BTW right now, the ...-alist type customizations don't dispatch on this-command but on the function being the ivy-state-collection.

I think, the new :caller field should be initialized with this-command in case it is not provided. Then you could have ...-alist entries for, e.g., switch-to-buffer instead of the rather obscure internal-complete-buffer.

However, dispatching on ivy-state-collection is still useful because it allows for having one internal-complete-buffer entry which can act as a default for all commands which read a buffer name instead of having to add entries with the same value for switch-to-buffer, pop-to-buffer, etc. So for all the ...-alist variables, I'd test if there's an entry for the current ivy-state-caller, and if not, check if there's an entry for ivy-state-collection if that's a function.