curusarn / resh

RESH ❯❯ Contextual shell history for zsh and bash
MIT License
1.01k stars 19 forks source link

Crtl+R binding doesn't work #156

Closed ondrejfuhrer closed 2 years ago

ondrejfuhrer commented 3 years ago

Hello, I have an issue with the Ctrl + R binding. If I try to re-register, it says, that it is already registered. But then when I try to use it, it uses "regular" search instead of resh

~ ❯ reshctl enable ctrl_r_binding
RESH SEARCH app Ctrl+R binding: ENABLED
RESH SEARCH app Ctrl+R binding is already enabled!
~ ❯
bck-i-search: _

I'm using iTerm2 (Build 3.4.3) and oh-my-zsh on Big Sur. Any ideas how to make it work? I remember that it worked earlier and then it just stopped.

Sciencentistguy commented 3 years ago

I have this too. Afaict its an incompatibility between resh and starship.

curusarn commented 2 years ago

Hey, I have fixed a bug in keybindings setup. It is possible that it will solve this issue. I would be happy to hear if it helped.

ondrejfuhrer commented 2 years ago

Hey @curusarn , thx for this. I've tested it for the time being and seems to be working fine. However there doesn't seem to be an option to enable the binding globally, is that expected?

As a workaround I used following in my ~/.zshrc :

reshctl enable ctrl_r_binding &>/dev/null

But not sure if that's expected and should be handled by such approach? Might be then worth updating the docs?

curusarn commented 2 years ago

Hey @ondrejfuhrer,

you are right that there used to be separate commands for enabling keybindings globally and "just for current session". But I decided that it's too complicated and merged both functionalities into one. So now, after running reshctl enable ctrl_r_binding the keybinding should be enabled for both current and future shell sessions.

This means that, you should not need to have reshctl enable ctrl_r_binding in your ~/.zshrc. Can you try remove reshctl enable ctrl_r_binding from ~/.zshrc to see if the Ctrl+R keybinding still works? Can you paste your ~/.config/resh.toml here?

A bit more of extra info: When you open a new terminal, resh reads ~/.config/resh.toml and activate the Ctrl+R keybinding if bindControlR is set to true in the config. Running reshctl enable ctrl_r_binding does two things: 1) sets bindControlR = true in the config 2) enables the keybinding in the current shell session

ondrejfuhrer commented 2 years ago

Hey @curusarn

Thanks for a quick reaction. I can confirm that without the "manual" setting it doesn't work, unfortunately. New sessions are not picking up the settings.

Here is my resh.toml:

port = 2627
sesswatchPeriodSeconds = 120
sesshistInitHistorySize = 1000
debug = false
bindArrowKeysBash = false
bindArrowKeysZsh = true
bindControlR = true

To me all looks good from that side, however doesn't seem to work as you described :-(

curusarn commented 2 years ago

This seems like something is weirdly interacting with resh in your ~/.zshrc. Are the lines added by resh at the end of your ~/.zshrc? E.g. sourcing oh-my-zsh after resh could break resh. Maybe you could paste your ~/.zshrc if you don't mind?

ondrejfuhrer commented 2 years ago

@curusarn ah nice, I moved those lines to the file end and that made it work. However there is on more thing - new shell for me starts with "red" > meaning the initialisation script ended with non-zero exit code.

The last lines are this:

[[ -f ~/.resh/shellrc ]] && source ~/.resh/shellrc # this line was added by RESH (Rich Enchanced Shell History)
[[ -f ~/.bash-preexec.sh ]] && source ~/.bash-preexec.sh # this line was added by RESH (Rich Enchanced Shell History)

Is there a way to debug what's happening? Or could that be since source ~/.resh/shellrc makes an output? 🤔 If I run the script "manually" it ends with 0 🤔

curusarn commented 2 years ago

This line:

[[ -f ~/.bash-preexec.sh ]] && source ~/.bash-preexec.sh # this line was added by RESH (Rich Enchanced Shell History)

is for bash only. If you have it in ~/.zshrc then remove it. It would make sense that it fails when evaluated by zsh. Let me know if it helps.

ondrejfuhrer commented 2 years ago

Yes, removing that helped! Great, thank you, closing the issue! 🚀