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

Expand candidate without closing the completion prompt #397

Open
1 task
musjj opened this issue Nov 24, 2023 · 4 comments
Open
1 task

Expand candidate without closing the completion prompt #397

musjj opened this issue Nov 24, 2023 · 4 comments
Labels
feature New feature request

Comments

@musjj
Copy link
Contributor

musjj commented Nov 24, 2023

Is your feature request related to a problem? Please describe

With the completion menu, you can't expand a candidate without closing the completion or moving into the selected directory. This feels unintuitive compared to the completion methods found in other editors/IDEs.

Will you be willing to contribute this feature?

  • Yes, I will try to implement it

Describe the solution you'd like

We should be able to expand a candidate without closing the window. To make this work, the first candidate should also not be automatically selected (which is the current default behavior).

For example:

/foo|
  foobar
  foo
  foobaz/

We can then press <Tab> a few times:

/foobar|
> foobar
  foo
  foobaz/
/foo|
  foobar
> foo
  foobaz/
/foobaz|
  foobar
  foo
> foobaz/

Then we can add / to enter into the subdirectory:

/foobaz/|
  child
  items

Describe alternatives you've considered

No response

Additional context

No response

@musjj musjj added the feature New feature request label Nov 24, 2023
@sxyazi
Copy link
Owner

sxyazi commented Nov 24, 2023

I have considered this approach, but it only allows "prefix matching". If there are multiple filenames in the directory with the same prefix, such as Cargo.toml and Cargo.lock, users would need to repeatedly switch between them using the <Tab> key.

If users want to modify the search keyword to make the results more accurate, they would need to cycle back to the first option or use a special "cancel key" to cancel the selection, which adds complexity.

In the current way, we can extend it by implementing fuzzy matching - "ct" matches "Cargo.toml", "cl" matches "Cargo.lock", and users only need to press <Tab> once.

@musjj
Copy link
Contributor Author

musjj commented Nov 24, 2023

If there are multiple filenames in the directory with the same prefix, such as Cargo.toml and Cargo.lock, users would need to repeatedly switch between them using the <Tab> key.

I'm not sure what you mean. Isn't this how it currently works (except that the first candidate is automatically selected)?

If users want to modify the search keyword to make the results more accurate, they would need to cycle back to the first option or use a special "cancel key" to cancel the selection, which adds complexity.

If the user wants to make the results more accurate, they can just keep on typing to narrow down the results before cycling through the candidates. That's how I usually do it in other editors. Actually, this also doesn't sound any different from how it currently works, can you clarify?

Fuzzy completion would definitely be an awesome addition though.

@sxyazi
Copy link
Owner

sxyazi commented Nov 24, 2023

Current autocomplete in Yazi is not just "prefix matching". If we implement the issue's approach would lead to:

/go|
  Cargo.toml
  Cargo.lock

then press <Tab>:

/Cargo.toml|
> Cargo.toml
  Cargo.lock

press <Tab>

/Cargo.lock|
  Cargo.toml
> Cargo.lock

press <Tab> again:

/go|
  Cargo.toml
  Cargo.lock

It changed from go to Cargo.toml, which is quite strange. I haven't seen this behavior in any editor/shell I've used. In contrast, Neovim is like this:

nvim.mp4

In zsh like this:

zsh.mp4

Their candidates start with ma or da that's user input.

@musjj
Copy link
Contributor Author

musjj commented Nov 24, 2023

It changed from go to Cargo.toml, which is quite strange. I haven't seen this behavior in any editor/shell I've used. In contrast, Neovim is like this:

Hmmm, I don't think it's strange. This is how my neovim's nvim-cmp works (I think it's pretty close to the default):

Peek.2023-11-24.21-35.webm

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature New feature request
Projects
None yet
Development

No branches or pull requests

2 participants