[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 Is it possible to show autocompletion proposals only if they are unambiguous? #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:

ble.sh/lib/core-complete.sh

Lines 6264 to 6273 in 2f564e6

	if local rex='^/?[-_a-zA-Z0-9.]+\+?[:=]|^-[^-/=:]'; [[ $COMPV =~ $rex ]]; then
	# var=filename --option=filename /I:filename など。
	local prefix=$BASH_REMATCH value=${COMPV:${#BASH_REMATCH}}
	local COMP_PREFIX=$prefix
	[[ :$comp_type: != *:[maA]:* && $value =~ ^.+/ ]] &&
	COMP_PREFIX=$prefix${BASH_REMATCH[0]}
	local ret cand "${_ble_complete_yield_varnames[@]/%/=}" # WA #D1570 checked
	ble/complete/source:file/.construct-pathname-pattern "$value"
	ble/complete/util/eval-pathname-expansion "$ret"; (($?==148)) && return 148

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 2f564e6. 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 #480 (comment) 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 :)