radian-software
Remember prescient filtering for selectrum-repeat
This is nice but would be much nicer if it remembered the prescient filter options - as it is I need to re-enable regexp with M-s r for example. Not sure where to raise this.
@raxod502 Maybe we could completely abandons this command for the time being? I don't think it adds much and mabye it gives to much room for potential problems with a lot of edge cases. Alternatively we could make the last input available via some other means, for example we could look into integrating it with the general idea of input history (#185 ).
Hmm, it adds a lot IMO since its way quicker than creating occur buffers. it's analogous to helm's restore candidates/status which was C-c h r iirc. But I'm new to this stuff so maybe use habits change. I was thrilled to find it ;)
I would rather ban it instead of adding complexity and a dependency to prescient. Alternatively consider moving it to prescient-selectrum? And you can always access the command/minibuffer history or wouldn't that work?
So you use this mainly to restore searches I assume? If you use embark you can quickly create a static buffer of your current results maybe that would be an alternative.
@clemera @rileyrg In the context of consult, there was also the feature request for something like ivy-resume, which is used to restore a completing-read session. But I consider it unnecessary. I copy some parts of my response https://github.com/minad/consult/issues/6#issuecomment-753729831 here:
- What about accessing the command history instead? It is not as comfortable but almost as good.
- Alternatively you can enable recursive minibuffers and jump out of the minibuffer for recursive editing, keeping the current session alive like this. This way you capture the continuation yourself. Basically the feature already exists in stock Emacs :)
- And then there is also Embark occur! This is what should be used if you want store a session!
I mostly agree, the only benefit I see that you don't have to think of it ahead of time. With the repeat functionality you can always restore the last matches after you quit.
@clemera I agree. But in the context of consult, I still reject it because of the immense complexity associated with a potential consult-resume/consult-repeat command.
Something like a occur buffer for the last session would be nice. Maybe one could setup minibuffer-exit-hook to save the last results into an occur buffer by default.
@clemera Oh this sounds like a great idea! Maybe this could be offered by Embark by default! I only wonder about the efficiency/slowdown of that, but it shouldn't be too bad? Please create an Embark issue for that!
@clemera Does it make sense to remove selectrum-repeat, if we have embark-repeat now?
I certainly wouldn't object to removing selectrum-repeat, though I suspect various users might have stronger feelings about it than I. If we've got the feature implemented in a more robust way in Embark, it sounds like we should drop it from Selectrum.
I use selectrum repeat. I don't use embark. It's very useful. But, I guess I can try embark again.
We don't have embark-repeat yet. This had to be reverted again for various reasons. However I think it is perfectly reasonable to remove certain features from selectrum as long as they fit better elsewhere in a completion-system agnostic way. This way we can avoid overlap between the packages. In any case I can highly recommend Embark. @rileyrg how is it going for you with the packages? Any new feedback/issues?
However I think it is perfectly reasonable to remove certain features from selectrum as long as they fit better elsewhere in a completion-system agnostic way.
I agree as long as the features aren't part of the default completion API (like for example completion-in-region which is the only place we currently have an overlap I think). As I see it Selectrum tries to provide a better UI for the default completion API so we should cover it completely with the new Selectrum like UI.
Sure, the completion ui should be fully covered. I consider this repeat command or the history/input history enhancements we discussed as more advanced features, which may be served better elsewhere. It should be decided on a case by case basis.