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

<TAB> completion does not work if the first attempt failed #6863

Closed
zx8 opened this issue Apr 5, 2020 · 6 comments
Closed

<TAB> completion does not work if the first attempt failed #6863

zx8 opened this issue Apr 5, 2020 · 6 comments
Labels
bug Something that's not working as intended
Milestone

Comments

@zx8
Copy link

zx8 commented Apr 5, 2020

Using 866d506

Let's say I'm waiting for an external process to create a file (e.g. /var/log/foo.log) but I don't know whether the file has been created yet, I might type something like:

$ less /var/log/fo<TAB>

If the file has not yet been created, I get the equivalent of printf '\a', as expected, and my terminal flashes - no problem here.

However, if I hit <TAB> again to check if the file has been created since my last <TAB>, nothing happens. No screen flash, nothing, as if tab-completion has been temporarily disabled.

In order to get around this, it is necessary to modify the commandline in some way in order to "re-enable" tab-completion, e.g. adding the next character or deleting the current character and hitting <TAB> again, but it would be great if I didn't have to, and instead simply had to hit <TAB> again without having to fudge the commandline first.

@ridiculousfish
Copy link
Member

Just a stupid bug - boolean with the wrong sense.

@ridiculousfish
Copy link
Member

Great bug, thank you for filing!

@ridiculousfish ridiculousfish added this to the fish 3.2.0 milestone Apr 6, 2020
@ridiculousfish ridiculousfish added the bug Something that's not working as intended label Apr 6, 2020
@ridiculousfish ridiculousfish reopened this Apr 6, 2020
@ridiculousfish
Copy link
Member

My fix seems to have broken other scenarios, it needs more work.

@krobelus
Copy link
Member

krobelus commented Apr 6, 2020

I have a fix that makes fish always recompute completions when hitting tab if there are no completions yet, see below.
However, when pressing and holding tab for some time on a command line with no (file) completions, fish will block because of all those queued completion requests. Cancelling with Control+C works, but after doing so, completion autoloading was broken on some of my attempts. Admittedly, this is an extreme example but maybe we should prevent this blocking behavior for example by limiting the number of consecutive complete commands.

diff --git a/src/reader.cpp b/src/reader.cpp
index f607cbff4..00fc9da83 100644
--- a/src/reader.cpp
+++ b/src/reader.cpp
@@ -2676,7 +2676,7 @@ void reader_data_t::handle_readline_command(readline_cmd_t c, readline_loop_stat
             // Use the command line only; it doesn't make sense to complete in any other line.
             editable_line_t *el = &command_line;
             if (is_navigating_pager_contents() ||
-                (!rls.complete_did_insert && rls.last_cmd == rl::complete)) {
+                (!rls.comp.empty() && !rls.complete_did_insert && rls.last_cmd == rl::complete)) {
                 // The user typed complete more than once in a row. If we are not yet fully
                 // disclosed, then become so; otherwise cycle through our available completions.
                 if (current_page_rendering.remaining_to_disclose > 0) {

@krobelus krobelus modified the milestones: fish 3.2.0, fish-future Apr 21, 2020
@zx8
Copy link
Author

zx8 commented Sep 16, 2020

@krobelus Any chance of getting that merged in, with potentially a follow-up to throttle input in future?

@krobelus
Copy link
Member

@zx8 Yeah, I think this is unlikely to cause any real problem, and Control+C still works. Thanks for the reminder!

@krobelus krobelus modified the milestones: fish-future, fish 3.2.0 Sep 17, 2020
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Dec 16, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Something that's not working as intended
Projects
None yet
Development

No branches or pull requests

3 participants