Several questions about ble.sh usage about ble.sh HOT 8 CLOSED

The first way on the wiki page is ~/.inputrc, but I think set -o vi in ~/.bashrc is a preferred way. I'll change the ordering of the ways on the wiki page. (edit: I edited the wiki page).

from ble.sh.

Vi/Vim mode

2. I enabled vi/vim mode in .inputrc file. And I also went through the vi/vim mode wiki page. But I still have no idea how to activate vi mode in my case.

The problem doesn't happen in my environment. What is the result of the following command?

$ ble/widget/display-shell-version

Basically, enabling the vi mode in ~/.inputrc should work. At least, as far as I try it now, it is enabled by just putting set editing-mode vi in ~/.inputrc. Is the vim mode not enabled in both macOS and SUSE? There are problems in the system inputrc (/etc/inputrc) distributed by openSUSE, so ble.sh ignores some of the settings in openSUSE, though I'm not sure if your "Linux SUSE" is actually openSUSE.

I even searched a youtube video abou it. It seems the video is kid of out-dated.

Could you provide the link to the video? I'm not aware of any YouTube video describing how to enable the Vim mode in ble.sh.

So my question is how to activate vi mode.

There are other ways to enable the vi mode. Have you tried any other ways describe on the wiki page? A standard way is to put

set -o vi

(edit: sorry vi was missing above. I corrected it.) in ~/.bashrc or in ~/.blerc.

Extra line on startup

3. I set up ble.sh in my .bashrc file, added the line in begin and end of bashrc. but every time I sourced bashrc file, there are some indents there, as below,

Does that cursor shift happen only for the first prompt? Or does it happen on every prompt?

What are the results of the following commands?

$ declare -p PROMPT_COMMAND
$ declare -p PS1

from ble.sh.

I'm using SLES15-SP4.

output of ble/widget/display-shell-version

ble/widget/display-shell-version

GNU bash, version 4.4.23(1)-release (x86_64-suse-linux) [SUSE Linux Enterprise Server 15 SP4]
ble.sh, version 0.4.0-devel4+b6344b3 (noarch) [git 2.35.3, GNU Make 4.2.1, GNU Awk 4.2.1, API: 2.0]
bash-completion, version 2.7 (hash:3f8d04b941aec802171b498397e6fa94ca88db2d, 73871 bytes) (noarch)
starship, version 1.18.1-master (rustc 1.77.0 (aedd173a2 2024-03-17), 2024-03-24 09:54:35 +00:00)
locale: LANG=en_US.UTF-8
terminal: TERM=screen-256color wcwidth=15.1-west/15.1-2+ri, tmux:0 (84;0;0), tmux:0 (84;0;0)

The youtube link

https://www.youtube.com/watch?v=rFNzCMU-wlI
I saw we could select using C-SP in the video, but it doesn't work on my machine.

Putting set -o vi in .blerc file and source it.

Great, thank you for your help. It now works like a charm. formerly I just tried the .inputrc way. So it did have some issues on SLES15-SP4 system.

Extra line on startup

Okay, before vi mode works, it only occurs for the first prompt. After vi mode enabled, no such issues any more.

Thank you very much for your reply. I can say for now it looks good to me. It is really a wonderful utility. I like it a lot.

from ble.sh.

Vim mode setting in inputrc

I'm using SLES15-SP4.

output of ble/widget/display-shell-version

ble/widget/display-shell-version

GNU bash, version 4.4.23(1)-release (x86_64-suse-linux) [SUSE Linux Enterprise Server 15 SP4]

Thank you. This means that ble.sh doesn't disable the system's inputrc since ble.sh detects the string "openSUSE" in the above line. I'm not sure why putting the setting in your ~/.inputrc didn't work. Maybe you set a variable INPUTRC? You might try running the following command to see if the variable INPUTRC exists and set to some value.

$ declare -p INPUTRC

Putting set -o vi in .blerc file and source it.
Great, thank you for your help. It now works like a charm. formerly I just tried the .inputrc way. So it did have some issues on SLES15-SP4 system.

Great!

Extra line on the first prompt

starship, version 1.18.1-master (rustc 1.77.0 (aedd173a2 2024-03-17), 2024-03-24 09:54:35 +00:00)

You seem to use starship. Maybe the extra line you observed is related to the starship. Maybe you want to check this comment: starship/starship#560 (comment).

Extra line on startup
Okay, before vi mode works, it only occurs for the first prompt. After vi mode enabled, no such issues any more.

OK!

C-SP key to start selection

terminal: TERM=screen-256color wcwidth=15.1-west/15.1-2+ri, tmux:0 (84;0;0), tmux:0 (84;0;0)

Do you use tmux? Maybe some of the settings for the keyboard interaction is interfering. You might also check the tmux section in Manual A2 Terminal Settings · akinomyoga/ble.sh Wiki.

The youtube link
https://www.youtube.com/watch?v=rFNzCMU-wlI I saw we could select using C-SP in the video, but it doesn't work on my machine.

Thanks for the link! So the video seems to be just a copy of the animated GIF in ble.sh's README. I created the animated GIF, but someone seemed to have uploaded it to YouTube.

For the C-SP, the current version of ble.sh still interprets it as the starting selection. The key combination C-SP (Control plus Space) is one of the most basic key combinations in terminal communication, so I'm not sure why it's not working in your environment. Another possibility would be that the designed behavior of C-SP is different from your expectations.

What would you expect by pressing C-SP? C-SP is intended for starting the selection mode. Only pressing C-SP doesn't change any appearance. One needs to move the cursor after pressing C-SP. Then, the range between "the current cursor position" and "the position where the cursor existed when C-SP is pressed" is selected.

Thank you very much for your reply. I can say for now it looks good to me. It is really a wonderful utility. I like it a lot.

Thanks!

from ble.sh.

...Maybe you set a variable INPUTRC?...declare -p INPUTRC

No, I didn't set this variable and the output is as below,
❯ declare -p INPUTRC -bash: declare: INPUTRC: not found [ble: exit 1]

Maybe you want to check this comment: starship/starship#560 (comment).

No, if I set the option as empty-line, the issue occurs again. The default bleopt prompt_ruler=empty-line works as expected.

For the C-SP, ..., so I'm not sure why it's not working in your environment.

Well I managed to find the root cause. It was because C-SP was binded to the input method switch on Mac. I could make use of it after disabling the system keymap.

Thank you. Now it is even better.

from ble.sh.

Vim mode setting in inputrc

...Maybe you set a variable INPUTRC?...declare -p INPUTRC

No, I didn't set this variable and the output is as below, ❯ declare -p INPUTRC -bash: declare: INPUTRC: not found [ble: exit 1]

Thanks for the information! Hmm, so it means that there is another cause. Anyway, set -o vi in ~/.bashrc seems to work in your environment, so it should be fine.

Extra line on the first prompt

Maybe you want to check this comment: starship/starship#560 (comment).

No, if I set the option as empty-line, the issue occurs again.

So, setting empty-line causes the issue?

The default bleopt prompt_ruler=empty-line works as expected.

So setting empty-line works as expected?

I'm confused about whether setting empty-line causes the issue or does not cause the issue.

The suggestion in the original thread is to use bleopt prompt_ruler=empty-line instead of add_newline = true; if you had the Starship setting add_newline = true, you should instead set add_newline = false in the Starship configuration and set bleopt prompt_ruler=empty-line in ~/.blerc (or ~/.config/blesh/init.sh, etc.).

C-SP key to start selection

For the C-SP, ..., so I'm not sure why it's not working in your environment.

Well I managed to find the root cause.

Great!

Do you have further questions? If not, I guess I can close the issue?

from ble.sh.

apologize for the confusion. I forgot to change it. It's the default bleopt prompt_ruler=' ' that works. yes please help to close the thread. thank you for all the replies!

from ble.sh.

Thank you for the confirmation!

I forgot to change it. It's the default bleopt prompt_ruler=' ' that works.

I again tried bleopt prompt_ruler=empty-line with Starship but the problem doesn't reproduce in my environment.

yes please help to close the thread.

There seems to be still something unresolved. I'd like to resolve the issue, but I'll have to close the issues as long as the user finds a working way because the unresolved issues are stacking up recently.

Thanks.

from ble.sh.