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

Improve undoing fuzzy completion matches #7433

Closed
faho opened this issue Oct 28, 2020 · 6 comments
Closed

Improve undoing fuzzy completion matches #7433

faho opened this issue Oct 28, 2020 · 6 comments

Comments

@faho
Copy link
Member

faho commented Oct 28, 2020

On StackOverflow someone complained that it's sometimes unwanted to turn something like /etc/ft into /etc/fstab.

In that case it was a fuzzy match (a "fuzzy_match_subsequence_insertions_only" match to be precise), because "ft" fuzzy-matches "fstab", but really it was just a typo.

Of course it's always possible to use undo (well, once 3.2 is released), but that requires an extra binding you have to know about.

I think we might find a way to do better.

Some idle ideas:

  • Always open the pager if the match is fuzzy
  • Allow "cancel" (i.e. escape) to undo a completion if pressed right after it (this would work for all types of completion matches)
@krobelus
Copy link
Member

I like the cancel idea. Redoing is also intuitive by pressing tab again.

Maybe disable it when the pager was used to select a completion,
because that's harder to redo after accidentally pressing escape.
Also, in the pager the user manually confirms any fuzzy match, so the motivating problem doesn't really exist here.

@faho faho closed this as completed in d334dc6 Oct 30, 2020
@tal-zvon
Copy link

tal-zvon commented Oct 30, 2020

I was the one on stack overflow complaining. Thanks faho for the reply.
Just to repeat the example I gave on stack overflow for this, this is what happens to me when working on a file in a git repo:

  • I have a file in the current directory named lib.py that has been modified since my last commit
  • I type git difftool li and hit <tab>, expecting to end up with git difftool lib.py
  • Fish replaces what I wrote with git difftool templates/nxt_connect/dish_controls.html, because from what I understand, it doesn't have a built-in completion file for git difftool so it doesn't even check the current directory for files when I hit tab

At this point, I have 2 options:

  1. Hold backspace for several seconds until I delete the arg it filled in (templates/nxt_connect/dish_controls.html), and replace it with lib.py; OR
  2. Hit Ctrl+u to delete my entire line, and start from scratch

Because I can type "git difftool" faster than waiting for backspace to delete that long string, I choose option 2. This basically means that fish's autocompletion messed up so bad that it was easier for me to delete the entire line, and start from scratch, than fix it by hand.

An undo function would be nice.

The bigger issue I have with this is that fish tries to be smarter than the user. It decides that what the user wrote isn't what he meant, and that it will delete what he wrote, and replace it with something else, which some people might be ok with, but others are not. I find it incredibly annoying, and wish there was a way to disable this.

faho mentioned on stack overflow that this probably won't happen. That's too bad. If you guys think this "feature" deserves to be enabled by default, that's fine - perhaps the majority of users like this. I don't know. I just wish those who are like me, that find this annoying, and are willing to do a quick search online for a way to disable this could have a simple flag in some config file that they could set to do just that.

@faho
Copy link
Member Author

faho commented Oct 30, 2020

@terminator14 Please check what the issue actually does.

An undo function would be nice.

This is now implemented. All you have to do in the next release is press escape after the completion was accepted, and it will undo that acceptance.

So you enter ls /etc/ft, press TAB, that turns it to ls /etc/fstab, press escape, that turns it back to ls /etc/ft.

In addition to that, the next release has a general undo functionality, bound to ctrl-z, so you can press that to undo any change to the commandline.

are willing to do a quick search online for a way to disable this could have a simple flag in some config file that they could set to do just that.

Again: This is not how fish operates. We try really really really hard not to make things an option.

@tal-zvon
Copy link

tal-zvon commented Oct 30, 2020

You mentioned that on stack overflow. I don't quite understand - why are options bad? Almost every open source project has config files with options you can enable and disable. I, along with many others I'm sure, always thought options were a good thing.

I know that many people hate change, even if it's for the better. Is the idea with fish to make things considered positive changes non-optional, so people are forced to use them, get used to them, and learn to love them?

As this idea sounds controversial, I'm guessing there's a large discussion somewhere about why fish chooses to do this, and what should be an option, and what shouldn't?

@faho
Copy link
Member Author

faho commented Oct 30, 2020

I don't quite understand - why are options bad? Almost every open source project has config files with options you can enable and disable.

Please read our design document.

In short: Options are usually a cop-out when you can't bring yourself to just pick, and they increase the surface area and thereby make things worse, not better.

But anyway, I don't particularly want to debate this at length. In short: An option to disable this form of fuzzy matching won't be added. If you come up with a solution that doesn't include an option we can discuss it.

Personally, I'm happy with the cancel-undo. It has basically the same number of keypresses as requiring you to select the completion would have, it's intuitive, simple, and much less disruptive for current users.

@tal-zvon
Copy link

I see. Had a quick look. Some of the points in the document I agree with. Others I don't, but like you said, this isn't the place to debate that.

Thanks for the info.

@zanchey zanchey modified the milestones: fish-future, fish 3.2.0 Oct 31, 2020
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Apr 29, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants