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 selectrum-move-default-candidate #333

Conversation

clemera
Copy link
Collaborator

@clemera clemera commented Jan 8, 2021

@minad I'm not still not sure I would like selectrum metadata, I failed to find the discussion where you brought up arguments why it would be preferable to you, for now I made the variable public you are using public at least.

@clemera clemera changed the title Make selectrum-move-default-candidate public Add selectrum-move-default-candidate Jan 8, 2021
@minad
Copy link
Contributor

minad commented Jan 8, 2021

@clemera I am also good with the way things are now, since I have all the selectrum stuff decoupled from the rest via the advice. So metadata would only help me when I set the variables in the consult--read directly. Therefore I am also good with the current way of doing things. If you merge this, I will adapt consult accordingly, such that it uses the public variable.

selectrum.el Outdated
@@ -1606,7 +1606,7 @@ Otherwise, just eval BODY."
(cl-defun selectrum-read
(prompt candidates &rest args &key
default-candidate initial-input require-match
history no-move-default-candidate
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why are you modifying the API? Is this not yet part of the released API or are you gradually downstripping the API (I am all for that!)

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well you are too fast as always :D

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, I should probably not watch this repository ;) Maybe I switch my watching mode to only watch branches/issues I am involved in. But this wouldn't have prevented me from looking here. Actually I just wanted to see if you already merged this, such that I should adapt Consult.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No problem, I'm not used to someone watching so sometimes I'm pushing intermediate states but I'm starting to adapt ;)

Copy link
Collaborator Author

@clemera clemera Jan 8, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So I will ignore the option for now, so this won't break any code but they would have to update it to use the variable. We could also wait and then do all breaking changes at once, would you prefer that?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I already answered independently, yes I would keep everything as is. And then just deprecate selectrum-read at once if this is what you are up to. I usually try to keep changes somehow separated instead of merging multiple things, but maybe my chaotic development style on the consult repo with many small commits suggests otherwise. Let's say I at least try to do it when implementing major features or large refactorings.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will continue in this PR to make selectrum-read private then. My hope is that not to many use it, the longer the wait the more could be affected anyway.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nah I will make it private in another PR and then continue with this one.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@minad I'm also glad to get some feedback, especially when as valuable as yours. I just have to change my habits a bit, I'm very used to push things once in a while, and I'm trying things along the way. When I add a changelog that tells usually that things are in a state how I would like to submit them.

@clemera clemera force-pushed the make-selectrum-move-default-candidate-public branch from 4f72653 to d2e9663 Compare January 8, 2021 17:29
selected initially. This is handy for `switch-to-buffer' and
friends, for which getting the candidate list out of order at all
is very confusing.
NO-MOVE-DEFAULT-CANDIDATE is ignored and only kept for backward
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I still wonder about this change. Why not just keep the current behavior?

My suggestion would be the following:

  1. Expose all the functionality to want to make customizable via variables. Variables are your preferred way and I think now that it is okay! At least when something like Rework state management #322 is under consideration.
  2. Make selectrum--read private and deprecate selectrum-read in favor of selectrum-completing-read
  3. Refactor selectrum--read as you see fit :)

Copy link
Collaborator Author

@clemera clemera Jan 8, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did it this way because I want the user option to have precedencoe. But I'm starting to think maybe we should just wait with this and make selectrum--read private first so we do it all in one go.

@clemera clemera marked this pull request as draft January 8, 2021 22:19
@minad minad mentioned this pull request Feb 15, 2021
@clemera
Copy link
Collaborator Author

clemera commented Feb 15, 2021

Done in #441

@clemera clemera closed this Feb 15, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

2 participants