omg it picked up my .inputrc stuff that matches my customization of fundamental vim keys and it works

[bkerin]

spoooooooky good

I made 'js' mean Esc long ago because I didn't like reaching for Esc or hitting C-[ and shifted the motion keys to jkl;

yeah then javascript came along and used js but why should I change it's the one that sucks

Home page doesn't even mention that it's looking at .inputrc that but I'm not clear how it's working if it doesn't since readline is out

[akinomyoga]

I made 'js' mean Esc long ago because I didn't like reaching for Esc or hitting C-[ and shifted the motion keys to jkl;

I usually use C-c for this. It is mostly the same as ESC except when we expect some action at the end of the insert mode such as <C-v><motion>I<text><C-[>.

Home page doesn't even mention that it's looking at .inputrc that but I'm not clear how it's working if it doesn't since readline is out

By default, ble.sh takes diff of the output of bind -p, etc. with its default. When you change the keybinding through ~/.inputrc or bind before sourcing ble.sh, it is first applied to Readline, and then ble.sh detects the changes in the Readline settings and apply the same to ble.sh's keybinding.

If you do not like the behavior, you can add the following option to source ble.sh in your ~/.bashrc:

# bashrc

source /path/to/ble.sh --noinputrc

Actually, ble.sh also implements an .inputrc parser. It is not used by default, but if you would like to use the ~/.inputrc parser instead of relying on the diff of the bind outputs, you can use either of the following options instead (in the latest master):

# bashrc

source /path/to/ble.sh --inputrc=all  # <-- load both the system /etc/inputrc and the user's ~/.inputrc
source /path/to/ble.sh --inputrc=user # <-- load only the user's ~/.inputrc

Maybe I should describe it in README.

[akinomyoga]

By the way, you might also be interested in the lib/vim-arpeggio module, which helps define keybindings of simultaneous keys, namely the keybinding that is triggered when multiple keys are pressed simultaneously within a configurable interval.

# bashrc

# Example:
function my/set-up-arpeggio {
  ble-import lib/vim-arpeggio
  bleopt vim_arpeggio_timeoutlen=30 # <-- you can specify the accepted interval between the two keys in milliseconds
  ble/lib/vim-arpeggio.sh/bind -m vi_imap -f jk vi_imap/normal-mode # <-- keybinding for the simultaneous keys j and k
}
blehook/eval-after-load keymap_vi my/set-up-arpeggio

[bkerin]

vim-arpeggio does look interesting also, thanks for mentioning it :)

[bkerin]

Yes lib/vim-arpeggio was the ticket for sure. In fact without this the timeout that readline uses (I think it's a default, at least I could't find anywhere where I set it now) doesn't make it to ble.sh at all (and .js ends up even more annoying to type :). Also the js binding doesn't cause incremental search to exit and put the found command on the command line as readline does for me. I don't think I have any .inputrc hiding that causes it to do that. I tried to use arpeggio to take me out of incremental search as well, like so: ble/lib/vim-arpeggio.sh/bind -m isearch -f js isearch/exit This mostly works, but it drops me back into insert mode, which is not what readline does (it puts you back into normal mode with the cursor positioned before the match). I'm guessing this will be easy to fix with a custom widget but thought you might like to know. I don't know if it's possible to automgically pick up the ~/.inputrc isearch behavior or not but it is a piece of readline behavior that's sort of burned onto my brain so if others are the same it might worth it. I'm attaching my .inputrc in case any of the few things that happen in it look relevant to you. Britton

…

On Mon, Feb 6, 2023 at 5:07 PM Koichi Murase ***@***.***> wrote: By the way, you might also be interested in the lib/vim-arpeggio module <https://github.com/akinomyoga/ble.sh/wiki/Manual-%C2%A76-Vim-Mode#65-module-libvim-arpeggio>, which helps define keybindings of simultaneous keys, namely the keybinding that is triggered when multiple keys are pressed simultaneously within a configurable interval. # bashrc # Example:function my/set-up-arpeggio { ble-import lib/vim-arpeggio bleopt vim_arpeggio_timeoutlen=30 # <-- you can specify the accepted interval between the two keys in milliseconds ble/lib/vim-arpeggio.sh/bind -m vi_imap -f jk vi_imap/normal-mode # <-- keybinding for the simultaneous keys j and k } blehook/eval-after-load keymap_vi my/set-up-arpeggio — Reply to this email directly, view it on GitHub <#272 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABYW7NCZ5V7CO5LZY2ES5VDWWGU4NANCNFSM6AAAAAAUTFNZKU> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[akinomyoga]

Thank you.

I can consider adjusting the behavior. I haven't actually carefully designed the incremental search in the vim normal mode (vi_nmap) because the incremental search originates from GNU Emacs, but the way the vim normal mode works is different from Emacs. Actually, by default, isearch is not bound to any key sequence in vi_nmap in ble.sh.

Hmm, I now tried the behavior of Readline, but the incremental search started in the insert mode (Readline vi-insert) takes us back to the insert mode in Readline. Although the incremental search started in the normal mode (Readline vi-command) takes us back to the normal mode as you seem to expect, ble.sh doesn't support isearch in the normal mode (ble.sh vi_nmap). If you try to bind it through .inputrc, the following message should be output and the isearch does not become available in the normal mode:

ble.sh (bind): unsupported readline function 'isearch'.

It is still possible to forcibly bind C-r to history-backward-isearch as

# blerc

ble-bind -m vi_nmap -f C-r history-isearch-backward

but in that case ble.sh already does what you want, i.e., it takes us back to the normal mode (vi_nmap) after exiting the isearch mode.

I think I am missing something. What do you think?

I'm attaching my .inputrc in case any of the few things that happen in it
look relevant to you.

I don't find the attachment. I think if you reply to GitHub via email, the attachment files are removed by GitHub, and only the text is posted to the Discussion page.

[akinomyoga]

To summarize, what I observe is

• Readline: isearch in vi-insert drops us into vi-insert after finishing
• Readline: isearch in vi-command drops us into vi-command after finishing
• ble.sh: isearch in vi_imap drops us into vi_imap after finishing (the same as Readline)
• ble.sh: One needs to use ble-bind to bind isearch in vi_nmap (the keybinding from .inputrc / bind is restricted)
• ble.sh: if it is bound, isearch in vi_nmap drops us into vi_nmap after finishing (the same as Readline)

I can just allow binding it from .inputrc and bind, but I'm not sure if that is what you request and if that solves your issue.

[bkerin]

On Tue, Feb 14, 2023 at 4:30 PM Koichi Murase ***@***.***> wrote: To summarize, what I observe is - Readline: isearch in vi-insert drops us into vi-insert after finishing

Yes. It turns out my particular setup uses: set keymap vi-insert "js":vi-movement-mode to get behavior similar to bash, and this is presumably why it drops me back into movement mode. Sorry for the confusion. As it happens I think going to movement mode after the history item is accepted is almost always a better behavior for vi setup, since movement is almost always going to be desired next and exiting the insertion-like isearch state and ending up in movement mode is consistent with what happens when text input mode is exited in vi as well. But the way you have it is definitely consistent with how native bash works. It looks like the behavior I'm used to can be done in ble.sh with a simple widget like so: ble/widget/isearch/exit ble/widget/vi_imap/normal-mode But I haven't tried this yet. By the way it seems the Design widgets in section 3.2 of the manual is broken (takes to Create new page web page).

- Readline: isearch in vi-command drops us into vi-command after finishing

Yes, and this is a fine arrangement.

- ble.sh: isearch in vi_imap drops us into vi_imap after finishing (the same as Readline)

Yes.

- ble.sh: One needs to use ble-bind to bind isearch in vi_nmap (the keybinding from .inputrc / bind is restricted) - ble.sh: if it is bound, isearch in vi_nmap drops us into vi_nmap after finishing (the same as Readline) I can just allow binding it from .inputrc and bind, but I'm not sure if that is what you request and if that solves your issue.

Isn't it native bash that binds C-r to isearch in normal mode, both win and without 'set -o vi'? It seems to work that way for me with my .inputrc moved to .inputrc.disabled in a bash --norc after doing only 'set -o vi'. I'm never entirely sure I don't have some setting that I made 10+ years ago hidden away somewhere though :) But I think that ble.sh should maybe do this by default also, at least if the binding isn't already used for something else. Applying other .inputrc bindings to isearch mode is also a good idea I guess. At least native bash appears to do it, since 'js' exiting isearch in my setup seems to be due to this stanza in my .inputrc: set keymap vi-insert "js":vi-movement-mode "\C-p":previous-history "\C-n":next-history It seems sort of ambitious though, since it's not really insert mode and many things probably don't work the same way. I do think isearch is worth working on even for vi users. It's one thing I kept from my ancient emacs days because it does seem to be quite a bit nicer than other reverse search modes. Thanks, Britton

…

— Reply to this email directly, view it on GitHub <#272 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABYW7NEKP3M4LNVLHZ7IYILWXQWUNANCNFSM6AAAAAAUTFNZKU> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[akinomyoga]

As it happens I think going to movement mode after the history item is
accepted is almost always a better behavior for vi setup, since movement is
almost always going to be desired next and exiting the insertion-like
isearch state and ending up in movement mode is consistent with what
happens when text input mode is exited in vi as well.

In vi/vim, the searches are usually called from the normal mode but not from the insert mode, and the isearch behavior of Bash/ble.sh in the normal mode takes us back to the normal mode, which can be somewhat consistent with vi/vim.

For isearch started from the insert mode, it is hard to consider it as the nested insert mode because the insert mode cannot be nested. Also, there is no direct way to start searches from the insert mode in vi/vim. If we would like to run a command without leaving the insert mode, we may use <C-o> in vim, like <C-o>/, but vi/vim takes us back to the insert mode in that case.

Anyway, the isearch feature started by C-r comes from GNU Emacs, so it should be consistent with GNU Emacs but not with vi/Vim. GNU Emacs's isearch mode just restores the original mode after finishing. It doesn't change the mode.

But the way you have it is definitely consistent with how native bash works.

Yes.

By the way it seems the Design widgets in section 3.2 of the manual is
broken (takes to Create new page web page).

It's just not yet translated into English. The page is a bit too technical and has been primarily a private note for me, so it was intially only written in Japanese.

Isn't it native bash that binds C-r to isearch in normal mode, both win and
without 'set -o vi'? It seems to work that way for me with my .inputrc
moved to .inputrc.disabled in a bash --norc after doing only 'set -o vi'.
I'm never entirely sure I don't have some setting that I made 10+ years ago
hidden away somewhere though :) But I think that ble.sh should maybe do
this by default also, at least if the binding isn't already used for
something else.

The binding is already used for redo. The aim of ble.sh's vi/vim mode is not to reproduce GNU Readline's "incomplete" vi implementation but to enhance it to have closer behaviors with vi/vim. Vi/vim has never provided isearch with C-r in the normal mode, and C-r is the key for redo.

Applying other .inputrc bindings to isearch mode is also a good idea I guess.

I don't think so. In the original Readline, the keybindings are mixed for isearch and for the other modes, but I don't think we can manage them consistently when the user defines arbitrary keybindings for the insert mode. How can we tell whether a keybinding in .inputrc is intended for both the insert mode and the isearch mode or only intended for the insert mode? If we think about the proper configuration interface, the setting for multiple behaviors that can be different depending on the user's preference should not be mixed. ble.sh provides a way to customize each, so please just use it.

At least native bash appears to do it, since 'js' exiting isearch
in my setup seems to be due to this stanza in my .inputrc:

I think this is a design mistake of GNU Readilne.

It seems sort of ambitious though, since it's not really insert mode and
many things probably don't work the same way.

Yes.

I do think isearch is worth working on even for vi users. It's one thing I
kept from my ancient emacs days because it does seem to be quite a bit
nicer than other reverse search modes.

I think I will add the custom setting for C-r in the .blerc template later.

[bkerin]

On Fri, Feb 17, 2023 at 8:20 PM Koichi Murase ***@***.***> wrote: As it happens I think going to movement mode after the history item is accepted is almost always a better behavior for vi setup, since movement is almost always going to be desired next and exiting the insertion-like isearch state and ending up in movement mode is consistent with what happens when text input mode is exited in vi as well. In vi/vim, the searches are usually called from the normal mode but not from the insert mode, and the isearch behavior of Bash/ble.sh in the normal mode takes us back to the normal mode, which can be somewhat consistent with vi/vim. For isearch started from the insert mode, it is hard to consider it as the nested insert mode because the insert mode cannot be nested. Also, there is no direct way to start searches from the insert mode in vi/vim. If we would like to run a command without leaving the insert mode, we may use <C-o> in vim, like <C-o>/, but vi/vim takes us back to the insert mode in that case. Anyway, the isearch feature started by C-r comes from GNU Emacs, so it should be consistent with GNU Emacs but not with vi/Vim. GNU Emacs's isearch mode just restores the original mode after finishing. It doesn't change the mode. But the way you have it is definitely consistent with how native bash works. Yes. By the way it seems the Design widgets in section 3.2 of the manual is broken (takes to Create new page web page). It's just not yet translated into English. The page is a bit too technical and has been primarily a private note for me, so it was intially only written in Japanese. Isn't it native bash that binds C-r to isearch in normal mode, both win and without 'set -o vi'? It seems to work that way for me with my .inputrc moved to .inputrc.disabled in a bash --norc after doing only 'set -o vi'. I'm never entirely sure I don't have some setting that I made 10+ years ago hidden away somewhere though :) But I think that ble.sh should maybe do this by default also, at least if the binding isn't already used for something else. The binding is already used for *redo*. The aim of ble.sh's vi/vim mode is not to reproduce GNU Readline's "*incomplete*" vi implementation but to enhance it to have closer behaviors with vi/vim. Vi/vim has never provided isearch with C-r in the normal mode, and C-r is the key for *redo*.

I should try to learn that instead of typing :redo all the time :)

Applying other .inputrc bindings to isearch mode is also a good idea I guess. I don't think so. In the original Readline, the keybindings are mixed for isearch and for the other modes, but I don't think we can manage them consistently when the user defines arbitrary keybindings for the insert mode. How can we tell whether a keybinding in .inputrc is intended for both the insert mode and the isearch mode or only intended for the insert mode? If we think about the proper configuration interface, the setting for multiple behaviors that can be different depending on the user's preference should not be mixed. ble.sh provides a way to customize each, so please just use it. At least native bash appears to do it, since 'js' exiting isearch in my setup seems to be due to this stanza in my .inputrc: I think this is a design mistake of GNU Readilne.

Agreed.

It seems sort of ambitious though, since it's not really insert mode and many things probably don't work the same way. Yes. I do think isearch is worth working on even for vi users. It's one thing I kept from my ancient emacs days because it does seem to be quite a bit nicer than other reverse search modes. I think I will add the custom setting for C-r in the .blerc template later.

Makes sense. As you say it depends how far you want to go maintaining bash behaviors vs. more faithfully implementing vim UI, and in cases like C-r where there is no explicit setting in user configuration the ble.sh philosophy suggests going with the improved vim UI. I recall reading an explicit warning that in cases where there was no delta ble.sh could not guarantee compatibility, for whatever reason it wasn't quite enough that it was immediately obvious what was going on here (in truth I think because I hadn't really consciously noticed how readline isearch works). It's a bit sad that the careful work to maintain all the user keys lulls the new user a bit while other issues like this lurk, but I don't know what more I would do about it myself. Britton

[akinomyoga]

I added the description on C-r in blerc.template and in the Wiki page of Vi (Vim) editing mode