[FR] Don't autocomplete sometimes

[pallaswept]

> ble summary
GNU bash, version 5.3.3(1)-release (x86_64-suse-linux) [openSUSE Tumbleweed]
ble.sh, version 0.4.0-nightly+8060b7a (noarch) [git 2.50.1, GNU Make 4.3, GNU Awk 5.2.1, API 3.2, PMA Avon 8-g1, (GNU MPFR 4.2.1, GNU MP 6.3.0)]
bash-completion, version 2.12.0 (hash:480ffcc6a751e55621ec526eb5dea7a0d86d9e72, 17877 bytes) (noarch)
fzf key-bindings, (hash:30b776a502a3ff1c2d6ef99810a964a660038dcd, 6494 bytes) (noarch) (integration: on)
fzf completion, (hash:c30c47bf7ee5029dbe195dbec6843bb9a63fd897, 20497 bytes) (noarch) (integration: on)
starship, version 1.23.0 (rustc 1.88.0 (6b00bc388 2025-06-23) (built from a source tarball), 2025-07-20 21:10:10 +00:00)
locale: LANG=en_DK.UTF-8 LC_ADDRESS=en_AU.UTF-8 LC_MEASUREMENT=C LC_MONETARY=en_AU.UTF-8 LC_NAME=en_AU.UTF-8 LC_NUMERIC=en_AU.UTF-8 LC_PAPER=en_AU.UTF-8 LC_TELEPHONE=en_AU.UTF-8 LC_TIME=C
terminal: TERM=xterm-256color wcwidth=15.0-west/16.0-2+ri, konsole:220380 (1;115;0)
options: +autocd +extglob +histappend -hostcomplete +inherit_errexit

Hello!

I love ble.sh to bits. I have noticed that there's one behaviour which often causes me a problem - I have autocomplete on, and showing immediately, and if I have to fix a typo, it will sometimes complete a filename from the current directory in the middle of my command. Because it is set to delay=1 it is nearly instant, but there is a slight delay, and often I press enter just as it completes, and enter the wrong command. I noticed this happens with the '.' key a lot, which makes it catch the first hidden file name in the current working directory.

I think that's actually 1 or 2 or 3 FR's in one, some combination of something like:

• Option to not autocomplete hidden files Like set match-hidden-files off, but working for autocomplete too (related to https://github.com/akinomyoga/ble.sh/issues/601?)
• Option to not autocomplete paths (only history and programs) Like bleopt complete_auto_history=1 but for paths, for eg bleopt complete_auto_paths=
• Option to avoid triggering autocomplete when editing in the middle of a word

Thank you for ble.sh. I have bad hands and it really helps me a lot to reduce the keystrokes I need to type a command! It's a big deal to me. Thank you!

[pallaswept]

Just posting an example I just hit:

I entered this command to search for installed packages on my system: zypper se -i KF6 But then I remembered I needed to see versions, which requires -s, so I pressed the up arrow to get the previous command, left arrow 5 times and pressed s, and I got this:

[akinomyoga]

I noticed this happens with the '.' key a lot, which makes it catch the first hidden file name in the current working directory.

I think that's actually 1 or 2 or 3 FR's in one, some combination of something like:

• Option to not autocomplete hidden files Like set match-hidden-files off, but working for autocomplete too

ble.sh's auto-complete already supports match-hidden-files, but I don't think match-hidden-files is related to the reported behavior. When the . key is pressed and . is inserted, dotfiles are generated regardless of match-hidden-files. What is suppressed by turning off match-hidden-files is the dotfile generation for the empty word (where even . hasn't yet been input).

(related to Is it possible to show autocompletion proposals only if they are unambiguous? #601?)

It's the request to show the completion suggestion only when the completion is unique (which was stuck because I wanted to reconsider the configuration interface for auto-complete). It's unrelated to the present behavior.

• Option to not autocomplete paths (only history and programs) Like bleopt complete_auto_history=1 but for paths, for eg bleopt complete_auto_paths=

This is #636.

• Option to avoid triggering autocomplete when editing in the middle of a word

This may be implemented.

Just posting an example I just hit:

I entered this command to search for installed packages on my system: zypper se -i KF6 But then I remembered I needed to see versions, which requires -s, so I pressed the up arrow to get the previous command, left arrow 5 times and pressed s, and I got this:

Unless you have a file named ./-istdin.xkm, ble.sh doesn't generate such a completion. The completion generation is based on the settings set up using the complete builtin, and -istdin.xkm is probably generated by such a completion setting. Or another possibility is that a completion source set by another module (histdb or Atuin's integration) generates the word -istdin.xkm. What is the result of the following command?

$ complete -p zypper

[pallaswept]

ble.sh's auto-complete already supports match-hidden-files

Hmm I was mistaken sorry. I thought that it would begin completion when it had the one more character. As in, just pressing . would not begin completion, but pressing .c would complete to .config.

As you have described it is tricky for me because it means that every time I press . then, if completion occurs, it will always match the first dotfile in the directory... Perhaps my problem is something different than I thought.

(related to Is it possible to show autocompletion proposals only if they are unambiguous? #601?)

It's the request to show the completion suggestion only when the completion is unique

My mistake again, because of the above misunderstanding, I had thought that match-hidden-files, was not working for autocomplete but only tab-complete, as described for complete_ambiguous= in that post.

• Option to not autocomplete paths (only history and programs) Like bleopt complete_auto_history=1 but for paths, for eg bleopt complete_auto_paths=

This is #636.

Thank you! I did search before I posted but I missed that one. I think this will solve my problem!

• Option to avoid triggering autocomplete when editing in the middle of a word

This may be implemented.

Thanks mate :)

Unless you have a file named ./-istdin.xkm, ble.sh doesn't generate such a completion.

There is a file named stdin.xkm in that directory. It definitely does this sometimes I promise! When I pressed s to edit my command, it completed to stdin.xkm from the files in the directory. This is like described above when I press . it will autocomplete to the first hidden file in the directory.

It does not always do this, I am unsure what makes the difference. when this is a problem for me it is only ever from paths, not commands or history. I also don't know why it ignored the -i from the completion. Maybe I have made some stupid mistake with my settings :(

. What is the result of the following command?

> complete -p zypper
bash: complete: zypper: no completion specification

Thanks for your help!

[pallaswept]

This is #636.

Thank you! I did search before I posted but I missed that one. I think this will solve my problem!

On closer inspection I am not sure if this will solve my problem. This seems like it will disable autocomplete for everything except history, which would be unfortunate, I do still want it to auto-complete commands and syntax and such.

[akinomyoga]

I entered this command to search for installed packages on my system: zypper se -i KF6 But then I remembered I needed to see versions, which requires -s, so I pressed the up arrow to get the previous command, left arrow 5 times and pressed s, and I got this:

Unless you have a file named ./-istdin.xkm, ble.sh doesn't generate such a completion. The completion generation is based on the settings set up using the complete builtin, and -istdin.xkm is probably generated by such a completion setting. Or another possibility is that a completion source set by another module (histdb or Atuin's integration) generates the word -istdin.xkm.

Sorry, this was wrong. It is ble.sh that produces the completion -i<filename>. It is generated here:

https://github.com/akinomyoga/ble.sh/blob/2f564e636f7b5dd99c4d9793277a93db29e81adf/lib/core-complete.sh#L6264-L6273

It is a fallback completion triggered when no completions are generated, and it generates filenames after : or = or any flag -?, though I'm currently unsure what would be a good configuration interface to control the behavior.

ble.sh's auto-complete already supports match-hidden-files

Hmm I was mistaken sorry. I thought that it would begin completion when it had the one more character. As in, just pressing . would not begin completion, but pressing .c would complete to .config.

As you have described it is tricky for me because it means that every time I press .

It doesn't reproduce in my environment. The autosuggestion of a dotfile is supposed to appear only when . is input as a first character of a word. Inserting . in other places shouldn't cause the suggestion of a dotfile. At least, in my environment, the reported behavior doesn't reproduce. Does that happen with a plain .blerc / .bashrc / .inputrc settings (please back up your ~/.bash_history before trying plain settings)?

• Option to avoid triggering autocomplete when editing in the middle of a word

This may be implemented.

Thanks mate :)

I implemented this as bleopt complete_auto_complete_opts=suppress-inside-word in commit 2f564e636f7b5dd99c4d9793277a93db29e81adf. In the latest master branch, you can use the following setting to suppress auto-complete when the character at the current cursor position is not included in the default COMP_WORDBREAKS:

# blerc

bleopt complete_auto_complete_opts+=suppress-inside-word

I also added similar settings, suppress-inside-line, syntax-suppress-ambiguous, syntax-suppress-empty. Check bleopt complete_auto_complete_opts for details.

[pallaswept]

It is a fallback completion triggered when no completions are generated, and it generates filenames after : or = or any flag -?, though I'm currently unsure what would be a good configuration interface to control the behavior.

Ahh yes this would be what I am seeing. I think I understand the connection to #636 now, the filename completion is part of the syntax completion, and the syntax completion sees the -? as an option and offers the filename as the argument. I tried syntax-disabled and it stopped the above problem, but of course it disabled all syntax completion, and I LOVE the syntax completion! (very nice with autocomplete and tab complete fzf showing descriptions)

It's quite tricky to think of how to deal with this... Should -is complete command syntax with the s option, or the filenames beginning with s? The argument and option not separated is fine, if the option requires an argument, but blesh can't always know if that is true, so blesh must assume one or the other. I guess it would require an option to 'assume separated tokens', so that it only suggests filenames after -? (with the space separator), or something like that.

It doesn't reproduce in my environment. The autosuggestion of a dotfile is supposed to appear only when . is input as a first character of a word.

I think this is what I'm seeing. For example, if I do grep foobar . then it will autocomplete from there:

But sometimes when we do ., we really mean . as the current directory. I thought that, with match-hidden-files off, it would only attempt to complete with one more letter, so it would need grep foobar .H to autocomplete as above. I guess another way to think of it is that . is a completion, or the command is already complete?

I see a similar problem with non-hidden files - a valid single-character filename is not recognised as 'complete'. For example if I do touch x so that the file 'x' exists, and then I get my earlier example zypper se -i KF6 from my history, press left arrow a few times, and press x:

The Xsession.d subdirectory did exist, owned by root. (I thought this [...] syntax means it is doing ambiguous completion but I do have bleopt complete_ambiguous="")

Any way, I guess that even if the directory does exist with that character first, I still would prefer that it isn't used as an arg like this.

I also noticed something new while testing this out with the new blesh:

I did sudo cp -r. and when I pressed the ., this happened. I had just commented on https://github.com/akinomyoga/ble.sh/issues/480#issuecomment-3419725906 so I tried it without the sudo and it did not do that. So maybe that is just a small glitch in the fix for #480 ?

After I post this I will create a new user on my system with a fresh bashrc/inputrc/init.sh and see if it is the same.

I also added similar settings, suppress-inside-line, syntax-suppress-ambiguous, syntax-suppress-empty. Check bleopt complete_auto_complete_opts for details.

I tried these and they seem to work as intended :)

[pallaswept]

Thanks for waiting so long, it took me a while to get time to do this.

False alarms

I created the new account, set the minimal settings to enable autocompletion, and couldn't reproduce this one (showing the completion in [] brackets):

Or this one (error when completing after sudo):

Also, ble.sh does recognise single-character filenames as complete now:

(If I press x one more time, it autocompletes to xxx as expected!)

Then I copied my init.sh and inputrc files and bashrc from this account to that account, and it was the same!

And what's really strange is that now after logging back into my usual account, I can't replicate them here any more, either! I do have the blesh script installed centrally (in /usr/share/ble.sh) but neither user has write access to those directories. Perhaps I made it refresh some cache or something, or maybe there was a lingering ble.sh session of the older version, which I was attaching to... Anyway, false alarm! All of those seem to be working now, with the updated blesh, after the testing. Weird but good 😆

My FR, refined :)

This behaviour is still present, but we discussed that and it seems expected (providing file names as argument completion for options without space separator):

• It would be really good to have an option to decide whether ble.sh provides filename completions for un-separated tokens. (Or maybe even after a delay, or minimum characters entered, or similar)

And this one (providing filename completion for . although . is complete and match-hidden-files is off):

• And perhaps an option to control completion of hidden files from the . token

And I already have a nice new option to prevent mid-word completions so thank you very much 🤩

[pallaswept]

I just came across a minor glitch which seems related. It's best described with this screenshot I think:

I ran the first command, then I pressed up to get it back, went to the start of the line and deleted kate, typed cava -p and it autocompleted the filename (expected as above) but it is autocompleting the hidden file, and I haven't pressed . yet. That seems odd?

[akinomyoga]

I think I understand the connection to #636 now, the filename completion is part of the syntax completion,

Ah, yes. It might be a bit tricky, but the syntax-based completion first detects the context of the current completion based on the parsed result, and it calls various types of completions. When the current context is in an argument to a normal command, it performs programmable completion (set up by complete) and fallback completions. The fallback completions include simple filename completions and completions in the form --option=<filename>, /I:<filename>, and -i<filename>. This is what you see now.

I tried syntax-disabled and it stopped the above problem, but of course it disabled all syntax completion,

Right.

and I LOVE the syntax completion! (very nice with autocomplete and tab complete fzf showing descriptions)

It's quite tricky to think of how to deal with this... Should -is complete command syntax with the s option, or the filenames beginning with s? The argument and option not separated is fine, if the option requires an argument, but blesh can't always know if that is true, so blesh must assume one or the other.

Yeah, when the context is not given, it is ambiguous. It can mean two separate flags -i and -s, or it can also mean the option argument -i<option-argument> with <option-argument> being s, depending on the command and the option letter.

I guess it would require an option to 'assume separated tokens', so that it only suggests filenames after -? (with the space separator), or something like that.

This is anyway fallback completion, so the current design of ble.sh tries to generate something that might be valid. Since ble.sh doesn't know the set of the option flags that the command supports, it doesn't generate a list of flag letters but only generates filenames as a possibility.

But sometimes when we do ., we really mean . as the current directory. I thought that, with match-hidden-files off, it would only attempt to complete with one more letter, so it would need grep foobar .H to autocomplete as above. I guess another way to think of it is that . is a completion, or the command is already complete?

auto-complete of ble.sh doesn't care about the case where the completion is already complete. In such a case, the user can ignore the auto-complete suggestion and press Enter to run the command without the part temporarily inserted by auto-complete.

The Xsession.d subdirectory did exist, owned by root. (I thought this `[...]` syntax means it is doing ambiguous completion but I do have `bleopt complete_ambiguous=""`)

The suggestion in the form [ ... ] appears when the auto-complete replaces an existing part (instead of just appending a string). The rewriting typically happens with the ambiguous completion, but it also happens with case-insensitive completion, where x is rewritten to X to match the directory name Xsession.d.

I also noticed something new while testing this out with the new blesh:

I did `sudo cp -r.` and when I pressed the `.`, this happened. I had just commented on [#480 (comment)](https://github.com/akinomyoga/ble.sh/issues/480#issuecomment-3419725906) so I tried it without the `sudo` and it did not do that. So maybe that is just a small glitch in the fix for [#480](https://github.com/akinomyoga/ble.sh/issues/480) ?

I cannot reproduce this error. Maybe modules of an old version of ble.sh is loaded in a session with a new version of ble.sh.

---

Thanks for waiting so long, it took me a while to get time to do this.

False alarms

I created the new account, set the minimal settings to enable autocompletion, and couldn't reproduce this one (showing the completion in [] brackets):

Maybe case-insensitive completion isn't enabled in the new environment. Case-insensitive completion is enabled by set completion-ignore-case on in ~/.inputrc or bind 'set completion-ignore-case on' in ~/.bashrc. Anyway, the behavior with [...] is the expected one when rewriting happens by the completion.

Or this one (error when completing after sudo):

Yeah, this is probably the issue with multiple versions of ble.sh.

Also, ble.sh does recognise single-character filenames as complete now:

(If I press `x` one more time, it autocompletes to `xxx` as expected!)

Hmm, history-based auto-complete source might be interfering, or again case-sensitive completion might affect the generated completions.

My FR, refined :)

This behaviour is still present, but we discussed that and it seems expected (providing file names as argument completion for options without space separator):

• It would be really good to have an option to decide whether ble.sh provides filename completions for un-separated tokens. (Or maybe even after a delay, or minimum characters entered, or similar)

I will add an option, but I again want to consider the configuration interface (i.e., whether I add a new bleopt or add a value in an existing bleopt).

And this one (providing filename completion for . although . is complete and match-hidden-files is off):

• And perhaps an option to control completion of hidden files from the . token

When . is already input, match-hidden-files is irrelevant, as I've already explained. I think this should be considered a case that an already input string is complete as one completion, but there is another string starting with it. In this case, ble.sh currently tries to suggest the latter, but we might add an option to suppress the auto-complete suggestion in this case.

[akinomyoga]

I just came across a minor glitch which seems related. It's best described with this screenshot I think:

I ran the first command, then I pressed up to get it back, went to the start of the line and deleted `kate`, typed `cava -p` and it autocompleted the filename (expected as above) but it is autocompleting the hidden file, and I haven't pressed `.` yet. That seems odd?

OK, this is because the fallback completion for -i<filename> is generated as a special type of completion candidates, so the filtering for filenames based on match-hidden-files isn't applied. I'll fix this later.

[pallaswept]

will add an option, but I again want to consider the configuration interface (i.e., whether I add a new bleopt or add a value in an existing bleopt).

I think this should be considered a case that an already input string is complete as one completion, but there is another string starting with it. In this case, ble.sh currently tries to suggest the latter, but we might add an option to suppress the auto-complete suggestion in this case.

I'll fix this later.

That's all perfect, thank you! I really appreciate you taking the time to work out these little details with me.