space (magic-space) is too aggressive

[wookayin]

Currently, it automatically accepts the completion when there are completions (automatically) being shown.

Say we want to type for a in 0 1 2; do. There is a.py that is file suggestion.

❯❯❯ for a|     
a.py          

Pressing space here, it will accept the completion:

❯❯❯ for a.py |
a.py         bin/         etc/     ...(more)

which should not be the case.

[weilbith]

Yes. Some behavior like in Vim for the completeopt setting with noinsert and noselect set. So you get the list populated, but you must manually trigger at least once the selection of the first entry (or any other) and complete. Would be awesome.

[marlonrichert]

@weilbith I don't use vim, so I have no idea what you're talking about there. Can you try to explain it in more detail?

[marlonrichert]

@wookayin @weilbith I updated the code. Can you test if it resolves the issue for you?

[wookayin]

Thanks for our update. The problem I mentioned in the issue is gone. However, there is still a (similar) problem behavior is still not intuitive. I think space should not match accept suggestions.

Suppose you have a following situation:

$ vim f|
fasd/

Pressing <space> accepts the suggestion, making the prompt like

$ vim fasd |
(Suggestions)

Well, one would have wanted 'vim f g h'. Suggestion should be accepted only when <TAB> is pressed IMHO.

Also, should also work similar to the 'longest' behavior as in vim's completeopt -- i.e. only insert the longest common text of the matches.

Given:

❯❯❯ vim zlo|
zlogin   zlogout        

Pressing <TAB> matches zlogin (the first match), not zlog. Note that this is the zsh's default tab completion behavior. --> UPDATE: This was reported also in #10.

[Dwight-D]

Seconding the request for removal of this feature. So far I have found magic space to render my terminal more or less unusable as it will often insert inappropriate suggestions. It's also quite difficult to turn off with the recent update.

[weilbith]

Yes, maybe it would be nice to configure some behavior of this plugin. Accepting the "best match" automatically with space is very aggressive. There will be always a special case where the completion could be wrong. Especially when constructing awkward and super special chain commands. :laughing:

[weilbith]

@weilbith I don't use vim, so I have no idea what you're talking about there. Can you try to explain it in more detail?

noinsert: while looping through the suggestion list don't insert the current entry automatically but the user must manually confirm/select the candidate.

noselect: if the suggestion list pops up, don't automatically select the first entry, but let the user himself decide to use the completion

[marlonrichert]

This one is very tricky to solve. Believe me, I have tried. Would one of you want to try your hand at it? I welcome all pull requests! 🙂

[wookayin]

Can we just simply disable space? There is no much value I think this magic-space adds.

[weilbith]

I'll go for customizing the keybindings anyways. So I'll need to unbind default bindings and add my own ones after this plugin got loaded. I would be also fine to just get the widgets and do the binding myself. But I understand that without any binding this plugin is useless. So to make it work out of the box they are necessary. I think this is a critical decision for every plugin. Some allow to configure an option to disable default bindings. The advantage is that I must not care about the source order. Having this automated bindkeys I must make sure that my own bindings using the same keys/trigger get defined afterwards.

[marlonrichert]

@wookayin @weilbith @Dwight-D I really don't want to give up on magic-space just yet. I just pushed in a new fix that makes all of the above disappear for me. Please git pull, try it out and let me know if it works for you, too. 🙂

[nisavid]

Thank you for looking into this, @marlonrichert. In my usage, I have indeed noticed some improvements to the magic-space behavior after your recent changes. However, I'm still seeing some cases in which it has issues. Below, I will give the two most recent problems that I encountered, and I'll post additional comments if I find others.

tar xf̭ ￫ space ￫ tar xfv ̭

After typing tar xf̭, there is one available completion, v. Pressing space auto-inserts v. Considering the unlikelihood that the omission of v was an accident, this should not happen. In this particular scenario, the auto-insertion is annoying but probably harmless, but there are surely other cases that follow this pattern where the corresponding auto-insertion significantly changes the effect of the command.

foo() { ((̭ } ￫ space ￫ foo() { (( } ̭

When defining an inline function, I often type the closing brace before the body, then move the cursor back to fill in the body. When any simple command (i.e. command, sublist, or pipeline component) within the body starts with (( (to begin an arithmetic expression), pressing space causes the cursor to skip past the function's closing brace before inserting the space character. There is no scenario in which this behavior is intended.

[nisavid]

Here's another problematic case.

print a̭ ￫ space ￫ print a-long-file-name ̭

If the working directory contains (if I understand correctly) any file that starts with the letter a (such as a-long-file-name, per the title above), then after typing print a, pressing space will auto-complete the first such file name before inserting the space character. This behavior would be reasonable if it followed Zsh's rules for spelling correction—for example, if one had typed a-long-file-nm and had set the max-errors style to 2 (or greater). However, this scenario does not fall under spelling correction. It is unclear to me why a is auto-completed to a-long-file-name, and I suspect that no user—not I, anyway—would desire this behavior.

[marlonrichert]

@nisavid Thanks for the very detailed reports! 👏🏽

I will investigate what is the best way to fix this and of course notify this thread when I’ve pushed in a fix.

[Mallchad]

I haven't used this plugin much yet, I like it very much already. But I have found simply commenting out bindkey ' ' magic-space to be good enough for me. I don't like fully automatic completion it throws me off. I think it would be nice to have a single variable to disable this.

[marlonrichert]

@wookayin

Also, should also work similar to the 'longest' behavior as in vim's completeopt -- i.e. only insert the longest common text of the matches.

Given:

❯❯❯ vim zlo| zlogin zlogout
Pressing matches zlogin (the first match), not zlog. Note that this is the zsh's default tab completion behavior.

With the input above, just type i and press Tab to get zlogin or type o and Tab to get zlogout. Especially for large listings, that's much faster than endlessly tabbing around. zsh-autocomplete is set up to match much more than just the beginning of the word or consecutive characters. You can type almost any of characters in the word you're looking for, as long as they are in the right order. So, if you have several matches to pick from, just try typing the next letter that they don't have in common. 🙂

Also, don't forget you can use the arrow keys in the completion menu. That, too, is often faster than tabbing around. (If you have fzf installed, zsh-autocomplete is auto-configured to let you open the menu with the Down arrow key.)

[marlonrichert]

@nisavid @wookayin @weilbith @Dwight-D All right, I've pushed in a fix. Rather than my previous approach of trying to check what not to correct, I've decided to use a whitelist of things that are safe to correct instead. With that, all of the cases you've listed above now pass, plus some more. Please give it a try. 🙂

Oh, and you can turn it off completely by adding the following to your .zshrc after sourcing zsh-autocomplete:

zstyle ':completion:correct-word:*' tag-order '-'

[marlonrichert]

Closing this now. Please let me know if it needs to be reopened.

[marlonrichert]

Well, gosh darn, I just discovered that zstyle ':completion:correct-word:*' tag-order '-' does not completely disable autocorrection, plus I found that there are still some cases for which autocorrection works incorrectly. 🙁 I'll have to investigate further on how to solve this.

[marlonrichert]

@nisavid @wookayin @weilbith @Dwight-D @Mallchad I just pushed in a major rewrite that hopefully fixes things once and for all. 😅

When you press Space, correction now works as follows:

1. Don't correct anything if…
   • …the word we're on can be expanded,
   • …completion offers an exact match.
   • …we're on an option.
2. If there is only one possible correction, insert it immediately.
3. If there are multiple corrections, pop up a menu with corrections plus what you actually typed, always as the last option.
   • This means that if the correction menu pops up, you can always press Arrow Up + Enter to revert the correction.
   • Works with all the normal completion menu key bindings (except Shift-Tab).

Plus:

• On the command line, press Undo (^_ in Zsh by default) to revert the correction without removing the space you just inserted! 😃
• In the corrections menu, press Undo once to close the menu, then Undo again to revert the correction.

Finally, to disable correction completely, add this to your .zshrc (after sourcing zsh-autocomplete):

zstyle ':completion:correct-word:*' max-errors 0

Or you can set max-errors to 1 to try stricter correction. (The default is 2.)

Hopefully, we can close this is issue now. 😁

[Mallchad]

Feels pretty fantastic so far. Nearly every feels just as it should be. Thank you. There's just one more problem that I think was mentioned in issue #17 It still lags sometimes. This is most notable when you try to type a path on it's own. (For executing files directly and searching for files with changing the working directory) This is what is shows when I try to do so. It feels a bit better then before now, before it would nearly lock when I typed a path.

[marlonrichert]

OK, I can reproduce that. It seems to occur only when using AUTO_CD.

But it's not related to this particular issue, so let's continue the discussion at #17, @Mallchad. 🙂

[marlonrichert]

I noticed a couple more edge cases where magic-space wasn't functioning correctly, so I pushed in another fix.

[marlonrichert]

Since I haven't heard any complaints anymore, I'm guessing this is fine now. Closing.

[marlonrichert]

@nisavid @wookayin @weilbith @Dwight-D @Mallchad I just wanted to let you know that 7256aebc89d2180be74bb242f80c1bd20e89d63a adds a new way to configure magic-space. Please see the Readme.