Selectrum: default value display is too intrusive

Created on 17 Dec 2020  路  20Comments  路  Source: raxod502/selectrum

I am experimenting with using the default value in the consult-buffer switcher, but I am annoyed by the intrusive and too verbose default value display of selectrum [default value: xxxxxxx]. Can this be disabled or formatted differently? icomplete does not show such a thing. But maybe using a default value is generally too intrusive and therefore the display is good?

@clemera See here for context https://github.com/minad/consult/issues/72

Most helpful comment

Ahh, there is the norecord argument for switch-to-buffer :)

All 20 comments

Usually the default is sorted to the top but when the default is not part of the collection it is shown like that. I also think it is a bit intrusive maybe we can simply show the string contents it in shadowed face after the cursor in this case.

@clemera Ah okay, I understand. Then it makes perfect sense! This was not clear to me. This issue can be closed then. Independently, what do you think about https://github.com/minad/consult/issues/72?

I like the behaviour, and BTW I really like the new tweaks you implemented for narrowing! Have you thought about a way to indicate which narrow prefixes are available? I think it could be nice to show them in a small window above the minibuffer similar to lv-window or something like that.

I like the behaviour

Which behavior? I modified it now such that the current file and current buffer are still shown in the list, other-buffer is selected as default. Furthermore I kicked out all open files from the recentf-list.

Have you thought about a way to indicate which narrow prefixes are available? I think it could be nice to show them in a small window above the minibuffer similar to lv-window or something like that.

This has already been implemented by (ab)using which-key. See https://github.com/oantolin/embark/issues/50
But you have to press the prefix key consult-narrow-key to get it.

Another option would be to show the keys as part of the prompt, this would not be very intrusive at least - but maybe still annoying.

"Switch to [bfmv]:"

Which behavior?

I meant the current one I pulled a few minutes ago, this one 6e02f78333badfcf0fb9144229d3f10c416b477e. Maybe the current buffer could be added so it is at the bottom? I think I would prefer that.

This has already been implemented by (ab)using which-key. See oantolin/embark#50
But you have to press the prefix key consult-narrow-key to get it.

That is nice! Maybe this could also be tweaked to get more automatic behaviour (optionally).

Another option would be to show the keys as part of the prompt, this would not be very intrusive at least - but maybe still annoying.

Hm, maybe they could be shown in the modeline.

I meant the current one I pulled a few minutes ago, this one 6e02f78333badfcf0fb9144229d3f10c416b477e. Maybe the current buffer could be added so it is at the bottom? I think I would prefer that.

Ok, I will try that out - remove the buffer from the list and add it to the end. But the current behavior is aligned with the standard switch-to-buffer behavior.

That is nice! Maybe this could also be tweaked to get more automatic behaviour (optionally).

You mean that it is automatically shown when calling consult-buffer after a delay or immediately? It is certainly possible to do that and trigger which key such that it shows the consult-narrow-key keymap. This can be done via advices, minibuffer-with-setup-hook etc. But I will probably not include such a thing by default. I am happy with the current behavior. If someone figures this out we can see how intrusive it is and either put it in or put it into the wiki or example config in the readme.

Hm, maybe they could be shown in the modeline.

I would not like that - I've never seen the modeline used for something like this.

@clemera

Ok, I will try that out - remove the buffer from the list and add it to the end. But the current behavior is aligned with the standard switch-to-buffer behavior.

I tried it. It works well, but I find it a bit weird. Why would you prefer that? Probably you like that the default selected candidate appears at the top of the list which is not the case if we do it as I have it right now?

EDIT: I think the ordering I would like the most is "other-buffer, current-buffer, rest-of-buffers". This is less weird since the recent current buffer is not appearing at the end and the default is still at the top. It is only a slight deviation from the default switch-to-buffer behavior.

You mean that it is automatically shown when calling consult-buffer after a delay or immediately? It is certainly possible to do that and trigger which key such that it shows the consult-narrow-key keymap. This can be done via advices, minibuffer-with-setup-hook etc. But I will probably not include such a thing by default. I am happy with the current behavior. If someone figures this out we can see how intrusive it is and either put it in or put it into the wiki or example config in the readme.

Personally I don't like to use a prefix key to see the options, but its also reasonable for you to not start including any hacks because of my preferences ;) Maybe using which-key is the wrong way for something what I have in mind anyway.

I would not like that - I've never seen the modeline used for something like this.

I would like it visually, though it makes the assumption you are not using a minibuffer frame so it wouldn't be universal. An alternative I thought about is showing them right aligned but this wouldn't work well with horizontal completion like icomplete. I think one can also put an overlay on the prompt so it appears above the prompt, maybe that could work out.

EDIT: I think the ordering I would like the most is "other-buffer, current-buffer, rest-of-buffers". This is less weird since the recent current buffer is not appearing at the end and the default is still at the top. It is only a slight deviation from the default switch-to-buffer behavior.

This is what I implemented now, see https://github.com/minad/consult/commit/2eb2fa51878b3236cce62317c8b416268c008452

Personally I don't like to use a prefix key to see the options, but its also reasonable for you to not start including any hacks because of my preferences ;) Maybe using which-key is the wrong way for something what I have in mind anyway.

Maybe at first you like that, but having used the functions for a while I guess you don't want to see the keys every time. But if you want, try to hack something and we can see if it makes sense. I've used lv before and it has to do quite a bit of work to get the window right. By using which-key, I am getting this for free without having to write any code.

I would like it visually, though it makes the assumption you are not using a minibuffer frame so it wouldn't be universal. An alternative I thought about is showing them right aligned but this wouldn't work well with horizontal completion like icomplete. I think one can also put an overlay on the prompt so it appears above the prompt, maybe that could work out.

Right aligned in the prompt? This I would probably like if you can make it work with both Selectrum and Icomplete-vertical. Above the prompt, I don't understand that - how is that different from "Switch to [bfmv]:"?

The current buffer was hidden before I think? Usually you don't want to select it which is why I thought it would be nice to have it at the end so it is there when you are really searching for it but it makes also sense to keep the buffer ordering more reasonable with regard to the real buffer list.

Maybe at first you like that, but having used the functions for a while I guess you don't want to see the keys every time. But if you want, try to hack something and we can see if it makes sense. I've used lv before and it has to do quite a bit of work to get the window right. By using which-key, I am getting this for free without having to write any code.

Yes, that repurposing which-key for this is nice. I was thinking not only about consult-buffer but also about other commands for which I might implement the prefix feature. Remembering all the prefixes will be hard so I would always like to see them.

Right aligned in the prompt? This I would probably like if you can make it work with both Selectrum and Icomplete-vertical. Above the prompt, I don't understand that - how is that different from "Switch to [bfmv]:"?

I'm not sure I could make it work I will try it next time I look at it. Above the prompt would be like an lv-window but showing it as an overlay:

b: buffers m: bookmarks\n
Switch to: ...

The current buffer was hidden before I think? Usually you don't want to select it which is why I thought it would be nice to have it at the end so it is there when you are really searching for it but it makes also sense to keep the buffer ordering more reasonable with regard to the real buffer list.

I am experimenting with it. It is not unreasonable. Right now my problem is that if you have preview enabled, it messes with the buffer-list. If I can avoid that, it would be so much nicer. And I like to have previews enabled. Basically preview buffer switches should not change the order of the buffer-list, the list should be reset afterwards.

Yes, that repurposing which-key for this is nice. I was thinking not only about consult-buffer but also about other commands for which I might implement the prefix feature. Remembering all the prefixes will be hard so I would always like to see them.

Yes, but you can always press the narrowing key. I have bound it to "<" in my config. If you don't like that you can also use a control key like "C-+".

I'm not sure I could make it work I will try it next time I look at it. Above the prompt would be like an lv-window but showing it as an overlay:

Ah okay I see, overlay but above? Not an extra window? But generally I would like to avoid more complexity being added to the narrowing system. The same keybinding issues apply to embark menus, there you also have everything below the prefix key, similar to the narrowing prefix key.

Ahh, there is the norecord argument for switch-to-buffer :)

Ah okay I see, overlay but above? Not an extra window? But generally I would like to avoid more complexity being added to the narrowing system. The same keybinding issues apply to embark menus, there you also have everything below the prefix key, similar to the narrowing prefix key.

Yes, no extra window, I think this could work well for all scenarios (minibuffer-frame, icomplete, selectrum) and I would also prefer that than prefixing the prompt with a potentially long help message. Yes for embark it is similar but there you only need it from time to time to trigger an action while I see the narrows keys as a more general driver of the UI, it would also be a nice indicator that the narrowing feature is available to you without having to press a key to check.

Ahh, there is the norecord argument for switch-to-buffer :)

Maybe for preview it would be better to use set-window-buffer, I believe switch-to-buffer can be configured to obey display actions.

Maybe for preview it would be better to use set-window-buffer, I believe switch-to-buffer can be configured to obey display actions.

Preview works well now for me. Also if using consult-buffer-other-window. I think I keep it for now like this. If an issue comes up, I can revisit.

Yes, no extra window, I think this could work well for all scenarios (minibuffer-frame, icomplete, selectrum) and I would also prefer that than prefixing the prompt with a potentially long help message. Yes for embark it is similar but there you only need it from time to time to trigger an action while I see the narrows keys as a more general driver of the UI, it would also be a nice indicator that the narrowing feature is available to you without having to press a key to check.

Why not just show "Switch to [bfmv]:" then? It is shorter, takes less space etc. And if someone wants to know what it means, just press the key. I would really prefer if we do not add more complexity to it regarding this feature. From my pov, this narrowing feature is already at the edge of getting too complex. It works well like it is :)

But if you feel like it, try to implement something and we can see if it is good. And if it is just hooked into the narrowing system from outside, I cannot say anything about it!

Why not just show "Switch to [bfmv]:" then?

I would prefer to see the options right away, I will see if my future usage will actually justify more work on this. For now I don't have written any custom commands.

Sure, I just started using this narrowing for a few commands. I like it in particular for imenu. And if you use the overlay view for sth else it is more justified to put work into this.

I like it in particular for imenu

That is a nice idea!

Was this page helpful?
0 / 5 - 0 ratings

Related issues

gcv picture gcv  路  9Comments

tinglycraniumplacidly picture tinglycraniumplacidly  路  13Comments

ashton314 picture ashton314  路  12Comments

adrianparvino picture adrianparvino  路  4Comments

piranha picture piranha  路  3Comments