You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I was going to write a bug report on ble.sh erroring out when one tries to edit arguments for find before -exec. Turns out this bug has already been fixed "upstream" in bash-completion and my distribution hasn't backported it.
The details are there (the error messages are the same), but since ble.sh tries to complete every time the user types something (and bugs like that can happen in a programmable completion system), I'm wondering if there's a way to silence them (at least while the user is typing). While it would mask bugs like those (kind of - there'd be "doesn't complete" bug reports), it would be less distracting.
In case it's relevant:
GNU bash, version 5.1.8(1)-release (x86_64-pc-linux-gnu)
ble.sh, version 0.4.0-devel3+a034c91 (noarch)
The text was updated successfully, but these errors were encountered:
Thank you for the discussion! Actually, this is one of the subtle points. Before 4fc51ae, I was actually redirecting stderr of the progcomp completions to /dev/null, but this caused a problem with fzf. fzf uses stderr to render its interfaces when it is called from the progcomp system. If we redirect stderr to /dev/null, the interface of fzf is not shown at all but still the user input is continued to be processed by fzf, which doesn't just work but also confuses users.
So I needed to decide whether we keep stderr connected to TTY as Bash's behavior respecting the completions which uses stderr, or we redirect stderr to silence broken completions. I chose the former. What we can do here for the broken completions is just making a blacklist of the broken completions and adding items after the corresponding report. Or another way is to patch the broken function by ble.sh as done in #97. If you have a better suggestion, it is welcome.
FYI: By the way, I forgot to tell you, but bash-completion #492, which I mentioned in #97, had been finally merged.
It seems like there is no better solution, so I just continue to patch bash-completion case by case. In commit d117973, I added a workaround for the error message produced in _find (defined in bash-completion).
akinomyoga
changed the title
Handling completion errors differently while the user types
[external completions] Handling completion errors differently while the user types
Oct 25, 2021
I was going to write a bug report on ble.sh erroring out when one tries to edit arguments for
find
before-exec
. Turns out this bug has already been fixed "upstream" in bash-completion and my distribution hasn't backported it.The details are there (the error messages are the same), but since ble.sh tries to complete every time the user types something (and bugs like that can happen in a programmable completion system), I'm wondering if there's a way to silence them (at least while the user is typing). While it would mask bugs like those (kind of - there'd be "doesn't complete" bug reports), it would be less distracting.
In case it's relevant:
GNU bash, version 5.1.8(1)-release (x86_64-pc-linux-gnu)
ble.sh, version 0.4.0-devel3+a034c91 (noarch)
The text was updated successfully, but these errors were encountered: