Better fix for the async filtering issue reported by @clemera

[minad]

See 0c9d6ab4fadfc3613880148bc1ed2c53cd851fbe

@clemera Can you please give it another quick test? It should work with the current Selectrum independent of selectrum-active-p. It seems to work for me in both cases, if the completion style is used by Selectrum and if it is not.

[clemera]

I think I would prefer using the flag approach (I changed it to be set early now), users might use other refinement functions which use completion styles, I know about one who adds ./ in file completions and calls selectrum-refine-candidates-using-completions-styles only in his customized version.

[clemera]

Another issue is when you check the refine/highlight function in early setup hook you won't get the values users might have set themselves via setup hook.

[minad]

Okay, I pushed the original fix again.

[clemera]

Thanks!

[minad]

@clemera ~It still does not work. I think your fix is bad, can you set somehow a higher priority? https://github.com/raxod502/selectrum/commit/257224bc7c5e97a52cc56cef2930f548af3a83e9~ disregard, I think I tested the wrong version...

EDIT: Okay, I confirmed that it works now. Please check.

[clemera]

Yes, things work for me now, too.

[minad]

Just to make it absolutely safe, did you try both with/without completion style?

[clemera]

Yes, although not in emacs -Q.

[clemera]

Hm, wait I'm using emacs -Q and still encounter some problems, I will report back.

[clemera]

I had some loading order issues apparently, filtering works now with both but when selecting a candidate it won't jump to the selected match.

[minad]

I just tried it again with emacs -Q. Seems to work for me.

[minad]

This should work:

(package-initialize)
(require 'consult)
(require 'selectrum)
(selectrum-mode)
(setq completion-styles '(substring))

Also this:

(load "consult.el")
(load "consult-selectrum.el")
(load "selectrum.el")
(selectrum-mode)
(setq completion-styles '(substring))

[clemera]

The filtering works but jumping to the match seems to be broken.

[minad]

For me it works. How did you load it?

[clemera]

I retried loading it as you described above, but I still can't jump to the matches, it seems @manuel-uberti has the same problem as reported here.

[clemera]

I used the manual loading you described second if that matters.

[minad]

@clemera @manuel-uberti Please try the newest main commit, see https://github.com/minad/consult/commit/eb72c233b34918346197602c0bf991e1da4aaa74. I tried to improve some flushing behavior but this seems to have broken the candidate lists, see #182.

[clemera]

Yes, this fixes it!

[manuel-uberti]

@clemera @manuel-uberti Please try the newest main commit, see eb72c23. I tried to improve some flushing behavior but this seems to have broken the candidate lists, see #182.

Thank you, consult-ripgrep works as expected now.

[minad]

@clemera @manuel-uberti Thank you both for checking again and the report!

[manuel-uberti]

Always glad to be of any help. [BTW: consult-ripgrep is just awesome.]

[minad]

Thank you very much, I am glad you like it!

[minad]

@manuel-uberti Btw, there is https://github.com/minad/consult/pull/170. What do you think about this approach? It will not be part of the Consult core package but I think there could be some additional consult-transient-grep package which allows to tweak the options via transient.

[manuel-uberti]

Interesting approach, it reminds me of rg.el which lets you refine the search criteria. Although, as per my use cases, consult-ripgrep suits me super well already.

[minad]

Yes, it would just be an add-on. You can summon the menu, it shows you the available options, you select and continue with the usual consult-ripgrep interface.