How to turn off the option completion and instead complete filenames?

[akinomyoga]

Let me move the issue carapace-sh/carapace-bin#1219 to here.

---

Originally posted by @geekscrapy in carapace-sh/carapace-bin#1219 (comment)

Firstly, great tool!

Hi, How can I turn off argument completion? I would prefer filenames/directories to be shown instead.

Second question: I loose some key bindings when I invoke ble.sh. For example I am on a mac (with iterm) and use ALT+DELETE to delete a previous word. This is disabled when I use ble.sh

[akinomyoga]

These are the replies made at carapace-sh/carapace-bin#1219:

---

Originally posted by @akinomyoga in carapace-sh/carapace-bin#1219 (comment)

Re: Filename completions for ls

Hi, How can I turn off argument completion? I would prefer filenames/directories to be shown instead.

@geekscrapy ble.sh combined with bash-completion by default is supposed to generate filenames and directory names for the empty-word completion. The behavior of the picture seems to be different from the default behavior of ble.sh. I would like to know the detailed setup in your environment.

• Q1 Which version of ble.sh do you use? If you are using ble-0.3, could you instead try ble-0.4? If you are not using the latest version of ble-0.4, could you update it to the latest master by running ble-update?

$ ble-update

• Q2 What would be shown by pressing [Ctrl+X][Ctrl+V] in a ble.sh session?

$ [press Ctrl+X][press Ctrl+V]

• Q3 What would be shown when you run the command complete -p ls?

$ complete -p ls

Re: ALT-DELETE in iTerm2

@geekscrapy It depends on the detailed terminal settings about what key sequences the terminal sends for ALT-DELETE. To check the sequence for the present setting, could you tell what would be shown after pressing [Ctrl+V][ALT+DELETE] in a ble.sh session?

$ echo [press Ctrl+V][press ALT+DELETE]     <-- Q. What will be shown?

Also, I'm interested in what would be sent by pressing [Ctrl+V][DELETE]

$ echo [press Ctrl+V][press DELETE]     <-- What will be shown?

Also, you might also want to check the description of ALT in iTerm2 under the item "M-right does not work in my terminal" on the Q&A page.

---

Originally posted by @geekscrapy in carapace-sh/carapace-bin#1219 (comment)

Hi! I'll be able to try it again after the weekend.
RE Q1 @akinomyoga , this was the first time I used ble.sh so I presume it would be up-to-date. I'll check though

(did my original issue get moved from the ble.sh issue list? I'd never heard of carapace before seeing this thread? Or maybe I was overtired 🙃)

[akinomyoga]

@geekscrapy Could you reply to this thread?

[akinomyoga]

@geekscrapy How's the situation? You can just give answers to Q1-3 and two more questions about ALT-DELETE in #204 (comment). In short, you can give us the result of the following commands and key inputs:

$ ble-update
$ [press Ctrl+X][press Ctrl+V]
$ complete -p ls
$ echo [press Ctrl+V][press ALT+DELETE]
$ echo [press Ctrl+V][press DELETE]

[geekscrapy]

Q1: Already up to date. (as of 2022-07-12)
Q2:

GNU bash, version 5.1.16(1)-release (x86_64-apple-darwin21.1.0)
ble.sh, version 0.4.0-devel3+14f3c81 (noarch)
locale: LANG=(unset) LC_COLLATE=C LC_CTYPE=UTF-8 LC_TERMINAL=iTerm2 LC_TERMINAL_VERSION=3.4.16
terminal: TERM=xterm-256color wcwidth=12.1-west/14.0-2+ri, xterm:95 (0;95;0)

Q3:

$ complete -p ls
-bash: complete: ls: no completion specification
[ble: exit 1]

[geekscrapy]

Re: ALT-DELETE in iTerm2

This issue has gone away for now oddly... I will keep an eye out for it coming back!

I am however getting the error: /bin/zsh: no such option: noprofile when the shell is loaded and .bash_profile is sourced. is this related?
Edit: Just did /usr/local/bin/bash --noprofile and re sourced .bash_profile and "no such option: noprofile" is no longer an issue

[akinomyoga]

Thank you for the information!

GNU bash, version 5.1.16(1)-release (x86_64-apple-darwin21.1.0)
ble.sh, version 0.4.0-devel3+14f3c81 (noarch)
locale: LANG=(unset) LC_COLLATE=C LC_CTYPE=UTF-8 LC_TERMINAL=iTerm2 LC_TERMINAL_VERSION=3.4.16
terminal: TERM=xterm-256color wcwidth=12.1-west/14.0-2+ri, xterm:95 (0;95;0)

Ah, OK. I got the situation! Actually, the filenames and directory names are also generated but do not fit in a terminal. If you attempt the completion in a sufficiently large terminal window, you will find the filenames at the end of the list. Here's an example of the completion in a larger terminal window where we see the filenames are shown at the end of the list:

.
The options precede the filenames because of the typical sorting order by LC_COLLATE. LC_COLLTE=C uses the character codes, and the hyphen - has a smaller code than the alphabets.

I have never cared about this situation, but now it seems reasonable not to generate option names when there are possible filenames considering the limited size of the window. I'll later adjust the behavior.

[geekscrapy]

Thanks! What might I be able to do to test this theory (and be a temporary fix?)

[akinomyoga]

If you want to test the theory, you can press Tab twice to enter menu-completion and press PageDns to go to next pages and see if the filenames are present in the last page.

[akinomyoga]

I have changed the ordering of the generation of options and filenames in commit 6954b13. Could you update ble.sh by running ble-update and see the behavior? Thank you.

[geekscrapy]

Yep, this works better now. If I'm honest I was actually expecting rows of the files like this:

$ echo /tmp/ble<TAB>
blesh boost_interprocess com.apple.launchd.gNBFSqjeAc com.google.Keystone tmp00005647 tmps28ku8b4cacert.pem

Although I get the column based selection. Is there a way to only ever get the row based menu like above rather than the column based one?

[akinomyoga]

How about this 1c7f7a1? Could you update ble.sh and check the behavior again?

[geekscrapy]

Woah, find that quite confusing with the arguments. But yes, without the arguments listed it would be great (for me 😄)

[akinomyoga]

that quite confusing with the arguments.

Oh, this is something unexpected. It doesn't reproduce in my Linux system. I guess this is related to the man page format used in macOS, but I cannot test it directly because I don't have macOS. I'm not sure if I can identify the problem without reproducing it, but will take a look at the related code later when I have time.

[geekscrapy]

that quite confusing with the arguments.

Oh, this is something unexpected. It doesn't reproduce in my Linux system. I guess this is related to the man page format used in macOS, but I cannot test it directly because I don't have macOS. I'm not sure if I can identify the problem without reproducing it, but will take a look at the related code later when I have time.

Fair enough, if I can assist please let me know

[akinomyoga]

@geekscrapy Sorry for the delay. I have added a workaround fa32829. I'm not sure if it really solves the problem in your environment because I don't have macOS. Could you update ble.sh by running ble-update in a ble.sh session and check the behavior?

[akinomyoga]

@geekscrapy Have you tried the latest version to see if the garbage string __ble_desc__ went away? If you are not using ble.sh anymore, that's fine, but could I close the issue? Thank you!

[geekscrapy]

Hey! Yes I stopped using ble.sh actually, I think I wanted simpler things 😅 so, it's fine to close
Thanks for the help though, keep going!

[akinomyoga]

OK, thank you for your response!