Zsh-autocomplete: Order and jump completion groups

[weilbith]

Just some new ideas to make this plugin even better as it is already.

I like to use the group option for the suggestion menu (disabled by default, zstyle ':autocomplete:*' groups 'always'). It looks more nice (personal opinion) and makes it more structured, understanding the suggestions even faster. The point is: sometimes I like to redorder the groups or jump between them. I must admit that I'm not too sure about the order I would like to set, but I would really appreciate the option to change it and tweak it over time, until I it works the best for me. So maybe sort directories over files is more convenient for my daily work. Not sure.
Nevertheless if I would find a good sort order, it would be absolutely awesome if I could jump between the groups. Continuing with the simple example of directories and files. And I know that I want to complete a directory, then I have to first iterate over all suggested files. Rather I would jump to the next group and then iterate through them. Maybe you are limited by zsh, I don't know. Maybe this is already natively supported and you must just teach us.

No matter the result, I love the plugin and every new feature makes it just a bigger work boost for a daily shell enthusiast.

[marlonrichert]

That's definitely possible. Thanks for the suggestion. I will make it. 🙂

[marlonrichert]

@weilbith If you check out the dev branch, you will be able to jump between completion groups with alt-up/down. Please try it out. 🙂

Currently, group order is chosen as follows:

1. If we are in the command position, then executable files and glob expansions are shown first (they go in the same group), then directories, then all other files, and then all other things.
2. If we are changing our present working directory, then glob expansions are shown first, and then directories (and hopefully nothing else).
3. In all other cases, all non-directory files are shown first, then directories, then glob expansions, and then all other things.

How would you like this to change? Always list dirs first?

[weilbith]

Cool. I'll give the jumping a test soon. (How)Can I configure the key-combo for the this command?

Hmm. Is there a fixed list of all possible group names (despite not all of them always apply)? Or is this out of your hands/depend on all the other completion sources?

[marlonrichert]

Cool. I'll give the jumping a test soon. (How)Can I configure the key-combo for the this command?

Currently, you can’t. It’s just ^[ (which is Alt, Escape or Meta, depending on your terminal) plus whatever you have for up or down. Why would this need to be configurable?

Hmm. Is there a fixed list of all possible group names (despite not all of them always apply)? Or is this out of your hands/depend on all the other completion sources?

No, there is no fixed list. Completion code can add whatever tags it likes and each tag can have an arbitrary group name assigned to it through the zstyle mechanism.

Can you give some examples of what you’re after?

[weilbith]

Why would this need to be configurable?

I think plugins should be as less opinionated as possible when it comes to
key-bindings. I understand that they define default to make the plugin working
out of the box. But it should always allow to disable the defaults and expose
options to set them manually, if the system (zsh here) does not allow so by
itself.
I'm pretty picky about my key bindings. So do I just a custom mech keyboard and have no arrow keys on my default layer. If I can avoid it I don't use arrow keys. Having this default binding totally disturb the type flow. For you and others this might be okay or it fits in your keyboard handling. :smiley:

No, there is no fixed list.

Ah well, that changes a lot. Is at least the directory, file, etc. basic stuff
fixed by zsh? :thinking:

Why would this need to be configurable?

Hmm. I think we should remove this out of this issues scope. I must admit that the idea was faster written than well thought through. I think having the jump feature will tell me which groups I jump over frequently. In future I might recognize a pattern. Then I can come back again and ask for this feature in a more precise manner. :D

[marlonrichert]

I think plugins should be as less opinionated as possible when it comes to
key-bindings. I understand that they define default to make the plugin working
out of the box. But it should always allow to disable the defaults and expose
options to set them manually, if the system (zsh here) does not allow so by
itself.

There's a couple of reasons why I don't introduce customization settings lightly:

• Configurations add complexity. The more different configurations are possible, the more time it takes to support the software.
• New settings are essentially new API. It takes some time to figure out exactly _how_ something should be configurable. And once that way is chosen, it's very hard to change it without breaking everyone installations.
• Naming things is hard. And again, once the name has been released, it becomes very hard to ever change it.

I'm pretty picky about my key bindings. So do I just a custom mech keyboard and have no arrow keys on my default layer. If I can avoid it I don't use arrow keys. Having this default binding totally disturb the type flow. For you and others this might be okay or it fits in your keyboard handling. :smiley:

I also have a mechanical keyboard without dedicated arrow keys, but I just solve this problem with a custom config for my keyboard. That way, I don't have to reconfigure any of the software I use. 🙂

[marlonrichert]

Also, you can use bindkey -s to map one key to another key or even a whole series of keys. So, if you just map your chosen key combination this way once to an arrow key, then it should work anywhere as an arrow key within Zsh.

[weilbith]

Hmm. I get you arguments. But I still think we have different opinions on that. I mean isn't it in fact just a widget that must become exposed? So you internally bound these keys already to something. That is named already. Once you reviewed that and merged to master I would assume you did your best to name it and there won't be spontaneously a better name in future.

The chain binding sounds like a bad solution for me. You can't simply read through your configuration anymore. A comment would be necessary to explain it. I rather have self explaining code. And maybe I'm wrong, but wouldn't this mean I theoretically loose the origin keys to rebind? I this specific case here I want to rebind it because I dislike the choice. But what if I use the keys already for another plugin? You introduce incompatibilities, since you never know what other plugins use or what user have configured.

Anyways. That is your valid opinion and it is you maintaining the code. I love that you implemented this feature. I will see how I tweak it for my setup. Maybe it just becomes a fork. I rather maintain to merge the upstream from time to time than bother my daily workflow. :shrug:

Thank you! :upside_down_face:

[marlonrichert]

@weilbith Don't close this just yet! I'm working on providing a way to customize this. I didn't mean to say "no". I just meant that I'm always very careful with implementing these kind of things. 🙂

[weilbith]

That is a good attitude. :+1:
I'm sorry for closing it so fast. I thought that's it. I don't want to annoy you with my opinion. The arguments where already raised. ^^

[marlonrichert]

@weilbith Can I ask, which key bindings would you use for this feature? And do you use the Arrow Up and Arrow Down bindings that zsh-autocomplete provides? If not, what key binding do you use to go back in/search? What key binding do you use to start completion menu selection?

[weilbith]

Answers not in the correct order: I decided to use tab and shift-tab for the menu selection stuff. I'm used to it by code completion and other stuff. I have a dedicated thumb key for tab, so I'm pretty happy with it.

Good question. Usually I start with something where I think that it may be comfortable/memorical and then adapt over time if it does not. The interesting question: Can I reuse a keybinding I set outside of the menu? So can I have them set already, but within the menu I can redefine them? :thinking:
I may would go initially with ctrl-space. I'm used to it for code snippets to jump to the next placeholder. So my brain is already kinda into use this for "jumps-to-next-whatever". :shrug:

[marlonrichert]

Thanks for your explanation. I still have to think about what would be the best way to present this customization setting to the other. If you have any suggestions, I'd love to hear about them. 🙂

Can I reuse a keybinding I set outside of the menu? So can I have them set already, but within the menu I can redefine them? 🤔

Yes, that's entirely possible.

[weilbith]

Thanks for your explanation. I still have to think about what would be the best way to present this customization setting to the other. If you have any suggestions, I'd love to hear about them. slightly_smiling_face

I think should finally have look to the code and research everything I don't understand. Or maybe watchout for a introduction to zsh its completion functionality.
I was assuming that this is just a widget you have written. And that I could now just bind it to the key-combo I like.

[marlonrichert]

I didn't even have to write a widget. It's just two lines of bindkey statements. 🙂

Regarding menu selection, this is the documentation you should be looking at: http://zsh.sourceforge.net/Doc/Release/Zsh-Modules.html#Menu-selection

I'm still interested in making this work well out of the box, though.

[weilbith]

Okay, so in fact this is a native feature of zsh within menus. So I could just add my own key-binding independently of this plugin. Correct?

So after all the remaining point is that you like the idea and provide your users with a default mapping for that. The issues is now to keep it configurable as I asked for. Right? So as it stands out to me, it could be pretty simple. The only case where your mappings could bother, is when the user had already used these keys for a custom binding that you overrule. Else he can simply set his own binding for what you do by himself. An according help/documentation would be awesome ofc. After all I think the only thing you need to do for preventing that issue is to check if the keys are already bound and skip if so, else apply these mappings straight forward. Either the user doesn't use the mapping or he can rewrite it as he want.
Does that make sense?

[marlonrichert]

Yeah, that makes sense and that's what I already had in mind, in fact. 🙂 Thanks! I'll implement it that way, then.

[marlonrichert]

@weilbith It's now available in the master branch.

[weilbith]

I'm back with a case for the order. You introduced the cool feature in #54 to integrate fast-jump directory/file tools like fasd. Their candidates have a higher priority than the "standard" suggestions. This leaves me often with the issue that I type just a few chars of a directory and hit tab to complete because I know it is there and completion should help me. Unfortunately these few chars match also a fasd candidate. That is likely with just a few chars typed. For cases where directories and files get suggested (e.g. cat) it is even worse. So I rather have the use-case that I need these suggestions by fasd when I want to access something that is not in this directory. So likely what I type does not exist in the current directory. So here the "standard" suggestions would be empty and I simply complete. Or I use the jump group binding to reach them. But since such completions are rare, I would rather go for the fasd candidates at the end of all groups.

[marlonrichert]

@weilbith For me, the "frequent or recent directory" group always appears _after_ the "directory" or "local directory" group, both on master and on dev and with both cd and AUTO_CD. You must have some option or zstyle that's messing with this. Can you please open a new issue for it and include a minimal test case? Thanks.