Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for history isearch #49

Closed
gcv opened this issue Apr 16, 2020 · 10 comments
Closed

Add support for history isearch #49

gcv opened this issue Apr 16, 2020 · 10 comments

Comments

@gcv
Copy link

gcv commented Apr 16, 2020

Incremental history search is very powerful, and it would be great if Selectrum supports it. So for example, C-x C-f would start a Selectrum-enabled file dialog, and C-r would search through file-name-history (or whichever history variable is appropriate for the given command). It would be especially great if the incremental search candidates could be shown in the Selectrum candidate narrowing display.

@raxod502
Copy link
Member

Let me know what you think.

@raxod502 raxod502 added the waiting on response Needs more info or follow-up, will be closed after 90 days if no response label Apr 18, 2020
@clemera
Copy link
Collaborator

clemera commented Apr 18, 2020

selectrum-select-from-history works great for me and I like that selecting the history element exits both recursion levels at once. If that was by accident I think this should be considered a feature not a bug. But for the general case selectrum should only exit the last recursion level.

@raxod502
Copy link
Member

That's intended, and indeed in the general case only one recursion level is exited.

@clemera
Copy link
Collaborator

clemera commented Apr 18, 2020

I see, nice! selectrum--exit-with runs twice though which means selectrum-candidate-selected-hook runs twice.

@gcv
Copy link
Author

gcv commented Apr 18, 2020

Excellent!! Thank you, this works really well.

@gcv gcv closed this as completed Apr 18, 2020
@raxod502
Copy link
Member

selectrum--exit-with runs twice though which means selectrum-candidate-selected-hook runs twice.

True; it's arguable either way whether this makes sense or not. (Another interesting question is "should the selected candidate from history selection be itself added to history, and if so which one?" Currently the answer is that we add it to minibuffer-history, because that was the most elegant thing to do in the code.)

@raxod502 raxod502 removed the waiting on response Needs more info or follow-up, will be closed after 90 days if no response label Apr 19, 2020
@clemera
Copy link
Collaborator

clemera commented Apr 19, 2020

should the selected candidate from history selection be itself added to history, and if so which one?

Good question, I think we should let bind minibuffer-history-variable and the hook so the selection of the history element within the history completion is ignored and has not state effects. That way it is just a helper to select an element from the original completion. The original completion should treat it like any other selection the user has done.

@raxod502
Copy link
Member

Okay, that's reasonable. Want to make a pull request for that?

@clemera
Copy link
Collaborator

clemera commented Apr 19, 2020

Sure, just has to wait a few days probably.

clemera added a commit to clemera/selectrum that referenced this issue Apr 24, 2020
@clemera
Copy link
Collaborator

clemera commented Apr 24, 2020

Done #72

raxod502 added a commit that referenced this issue Apr 26, 2020
Ignore selection side effects for history selection

See discussion in #49.

Also, if not within Selectrum insert result.

This allows inserting elements into minibuffer for
other minibuffer contexts like `eval-expression` and
`shell-command` where you don't want necessarily exit
with the result but insert it.

Co-Authored-By: Radon Rosborough <radon.neon@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

3 participants