Doesn't prevent conflicts between buffer selection keys and filter selection keys

[phil-s]

E.g. If A selects a buffer, then the user loses access to the [all] filter action. All the filter keys should be excluded from the list of potential buffer selection keys.

[waymondo]

I had realized there could be conflict as you've described, but I wasn't sold on the right solution. The selection characters are currently determined by frog-menu-avy-keys:

(defcustom frog-menu-avy-keys (append (string-to-list "asdflkjgh")
                                      (string-to-list "qwerpoiuty")
                                      (string-to-list "zxcvmnb")
                                      (string-to-list (upcase "asdflkjgh"))
                                      (string-to-list (upcase "qwerpoiuty"))
                                      (string-to-list (upcase "zxcvmnb"))
                                      (number-sequence ?, ?@))
  "Frog menu keys used for `avy-keys'.

By default uses a large collection of keys, so that the hints can
be drawn by single characters."
  :type '(repeat character))

asdflkjgh is the default set for selecting buffers, and the filter keys are set to AMFRPS or 123456, depending on the value of frog-jump-buffer-default-filters-capital-letters. The capital letters don't conflict with the lower case ones, so by default there is no conflict, but it is possible to configure incorrectly if you set frog-menu-avy-keys to a number sequence starting at 1, for example.

I think ideally there would be some validation that prevents this sort of mis-configuration. I don't think a filter or buffer select should necessarily take precedence over the other if they are set to the same key.

[phil-s]

Surely just filter out the frog keys when calling avy?

Avy does this:

(let ((avy-keys (or (cdr (assq ',command avy-keys-alist)) avy-keys))

So you can do the same thing to get the keys it would use, and then let-bind avy-keys-alist to a value which excludes all the frog keys for the relevant command.

[waymondo]

Thanks, that's a good solution.

[phil-s]

In fact I guess it's slightly simpler to let-bind both vars -- set avy-keys-alist to nil and avy-keys to the specific keys you ended up with. That way you don't need to create/modify an alist.

n.b. I haven't tested this, and I think it would be worth specifically testing the case where avy needs to read more than one character, to confirm there's no weird interactions which would cause it to see the original keys again.