Allow n/p to be repeated while holding down ctrl

[jondkinney]

...and tapping n or p

Instead of having to tap an an an or ap ap ap while holding control, you just do ctrl-a (in my case) and then hold control and tap n n n or p p p

Also, I think my code below will work, but the actual bindings I have are:

# Quick pane selection
bind -r C-p select-window -t :-
bind -r C-n select-window -t :+

[bruno-]

Hey, thanks for getting involved. I was experimenting with these bindings some time ago. There is a drawback to these because they conflict with the shell C-p and C-n bindings (used for going up and down in the shell command history).

Say you want to go 2 windows forward/next and then invoke previously executed command in that window. You do:

• prefix + C-n to go 1 window forward
• C-n to go yet another window forward
• C-p - you are in the desired window now and want to instruct shell to switch to previous command. That's C-p binding. But because we're still in tmux's repeat mode, tmux will catch the C-p and switch to previous window. That's not what a user wanted.

@jondkinney haven't you encountered this situation so far?

Because of the clear conflict described above, I'm going to close the PR.

[jondkinney]

@bruno- huh, I don't know what C-p is supposed to do in zsh, but it doesn't do anything other than print ^P. I've never used this feature that you speak of, but I do switch tmux windows about 200 times a day. So I definitely prefer my config since it speeds that up a lot. I'd even argue that it's a better default. If you want to execute the previous command you just press up arrow and enter, right? Or C-r to search back through your history for a command and then press enter? I pair with quite a few folks and haven't ever seen anyone use C-p. Are you sure it's worth worrying about? If you're dead set on it, then can you modify tmux-sensible so that it will allow me to re-define C-p and C-n? I'm fine having a non-standard config but if I add those mappings to my ~/.tmux.conf they don't work. Sensible-vim seems to override them.

[bruno-]

Hey, just to clear out the possibility I have a weird local setup: here's the link with bash keyboard shortcuts. The third and fourth from the top are C-p and C-n.. and it clearly states these are the equivalent to 'up' and 'down' arrows. Just wanted to show these are wide spread in bash world.

I'd even argue that it's a better default.

I agree! As previously mentioned, I wanted to enable these bindings, but I had to revert this due to bash defaults.

Are you sure it's worth worrying about?

Yea, unfortunately I think C-p and C-n are pretty popular in bash. Even the random bash shortcuts list from google listed these bindings near the top of the list. On the other hand, I find it curious that these do not come with zsh.

.. then can you modify tmux-sensible so that it will allow me to re-define C-p and C-n?

Absolutely! In fact, this should've already worked for you as it's one of the core plugin principles to not override user config.

So just to clarify, if you had these in your tmux.conf:

bind -r C-p select-window -t :-
bind -r C-n select-window -t :+

they should not\ be overridden by tmux-sensible! If they were, it's a bug (and I'll look into it immediately).

Anyway, re-reading your reply above I got the impression you're a bit disappointed I didn't accept the PR. Sorry about that, didn't want to be harsh. Hopefully in this post I've explained well enough why this could be problematic for other users.

[bruno-]

Just a quick update, it seems you were right. There is a bug in the plugin and key bindings with -r flag currently aren't detected properly and are overridden.

This is logged in #15. I think fixing this shouldn't be too hard.

[jondkinney]

Hi @bruno-,

No need to apologize, I understand where you're coming from. I guess I was just taken aback by C-p being a thing so it seemed like arbitrary push back. But since it does indeed sound like a thing then it makes sense not to break it.

But yea, I can't re-define C-p and C-n in my tmux conf when using tmux-sensible, so if you have some time to look into that bug that would be awesome. Thanks!

Jon

[bruno-]

Okay, I'm glad you understand.

About that issue in #15, it should now be fixed. Just update the plugin and it should work! I've tested this locally and it was fine, please report if you still see anything weird.

[jondkinney]

Awesome, thanks! Works great.