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

Restrict autocomplete to nearest whitespace #1505

Closed
aeonios opened this issue Jun 13, 2014 · 14 comments
Closed

Restrict autocomplete to nearest whitespace #1505

aeonios opened this issue Jun 13, 2014 · 14 comments
Assignees
Milestone

Comments

@aeonios
Copy link

@aeonios aeonios commented Jun 13, 2014

The current autocomplete behavior dictates that when you hit the right arrow key, the current suggestion is fully instantiated including all arguments. In many cases this behavior makes autocomplete useless, for example if I type 'w' for 'wget' and hit right arrow, I get wget+the link of whatever I downloaded last, which I then must delete before I can paste a new link. I've ended up typing out 'wget' manually instead simply because it's less work. Ideally, autocomplete should only complete to the next whitespace, and then push the cursor onto the first character of the next suggested argument without actually selecting it until you hit right arrow again. That would also make browsing through history items with a filter (or browsing complete options by typing) require fewer keystrokes.

There are some cases where one-argument selection behavior might make things slower, but I think it's acceptable as long as the behavior is consistent (which it currently doesn't feel like it). Rather, the current autocomplete behavior with directories works intuitively, but for commands does not.

@siteshwar
Copy link
Contributor

@siteshwar siteshwar commented Jun 13, 2014

ALT - Right Arrow does this.

@aeonios
Copy link
Author

@aeonios aeonios commented Jun 13, 2014

Not exactly, if an argument happens to contain backslashes (like a path or url) then alt - right arrow only completes to the next '/'. That's fine as an alt behavior, but in this case too small of chunks. There's no middle ground between completing one set of /*/ and the whole line, neither of which suits the default behavior well imo. At least for commands anyway.

@aeonios
Copy link
Author

@aeonios aeonios commented Jun 16, 2014

Another thing that should have been obvious, if you're working in a real console alt+arrow keys switches to a different console, and prevents you from using that functionality altogether.

@xfix
Copy link
Contributor

@xfix xfix commented Jun 17, 2014

@mtroyka: In this case, it's possible to use Meta + F.

@zanchey zanchey removed the duplicate label Jun 18, 2014
@ridiculousfish ridiculousfish added this to the fish-future milestone Oct 2, 2014
@krader1961 krader1961 removed this from the fish-future milestone Mar 23, 2017
@krader1961
Copy link
Contributor

@krader1961 krader1961 commented Mar 23, 2017

This is possible via the forward-bigword function which is already bound to several key sequences such as [ctrl-F] in emacs mode.

@krader1961 krader1961 closed this Mar 23, 2017
@faho
Copy link
Member

@faho faho commented Mar 23, 2017

already bound to several key sequences such as [ctrl-F] in emacs mode.

Note: "forward-bigword" is available, but not bound to anything by default.

@krader1961
Copy link
Contributor

@krader1961 krader1961 commented Mar 23, 2017

I had forgotten that I added it to my fish_user_key_bindings function. It is bound to some keys by default but only in vi mode, not default/emacs mode.

@floam
Copy link
Member

@floam floam commented Feb 7, 2019

Is this something we want to provide a bind for with the default keybindings?

@fish-shell fish-shell deleted a comment from jaredgrubb Feb 7, 2019
@faho
Copy link
Member

@faho faho commented Feb 7, 2019

The problem is finding a good key to put it on.

right-arrow is bound to forward-char (and should stay that way), so a modified version of that would work.

But ctrl-right is bound to forward-word and alt-right is bound to nextd-or-forward-word.

So unless we want to change one of those, we'd have to find a different combination.

@floam
Copy link
Member

@floam floam commented Feb 7, 2019

shift-left/shift-right isn't bound to anything (or at least isn't with the escapes my terminal sends)

@floam
Copy link
Member

@floam floam commented Feb 7, 2019

shift-right: [1;2C, which is actually bindable with just bind -k sright

@floam
Copy link
Member

@floam floam commented Feb 7, 2019

That seems totally fine, mind if I bind sleft to backward-bigword and sright to forward-bigword by default @faho?

@faho
Copy link
Member

@faho faho commented Feb 7, 2019

Yeah, that'll work.

@floam floam reopened this Feb 7, 2019
@floam floam self-assigned this Feb 7, 2019
@floam
Copy link
Member

@floam floam commented Feb 7, 2019

Fixed in 0abcf92 ... appear I referenced the wrong issue number in the commit message. (Doh!)

@floam floam closed this Feb 7, 2019
@floam floam added this to the fish 3.1.0 milestone Feb 7, 2019
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Apr 17, 2020
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

8 participants