Skip to content

feat(defaults): window navigation key maps #33696

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

antonk52
Copy link
Contributor

@antonk52 antonk52 commented Apr 28, 2025

Problem: default + HJKL is not an ergonomic way to navigate split windows

Solution: set default mappings to navigate with alt/option + HJKL

Context: Following this comment

@github-actions github-actions bot added the defaults Nvim defaults for options, colorscheme/theme, autocmds/events, etc. label Apr 28, 2025
@github-actions github-actions bot requested a review from gpanders April 28, 2025 21:10
Comment on lines +438 to +441
vim.keymap.set({ 't', 'i' }, '<A-h>', '<C-\\><C-n><C-w>h', { desc = 'Move to left window' })
vim.keymap.set({ 't', 'i' }, '<A-j>', '<C-\\><C-n><C-w>j', { desc = 'Move to down window' })
vim.keymap.set({ 't', 'i' }, '<A-k>', '<C-\\><C-n><C-w>k', { desc = 'Move to up window' })
vim.keymap.set({ 't', 'i' }, '<A-l>', '<C-\\><C-n><C-w>l', { desc = 'Move to right window' })
Copy link
Member

@zeertzjq zeertzjq Apr 29, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think mapping these in Terminal mode is a good idea, as it'll prevent using these keys in applications running inside terminal buffers. Switching window in Insert mode probably shouldn't be encouraged either, so maybe only map these in Normal mode?

Copy link
Contributor

@brianhuster brianhuster Apr 29, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Switching window in Insert mode probably shouldn't be encouraged either, so maybe only map these in Normal mode?

Probably shouldn't map in Normal mode as well, because it doesn't help with discoverability, since Nvim still doesn't have which-key, and neither does folke/which-key.nvim nor echasnovski/mini.clue work with <A- mapping, but they all work with normal mode <C-w> commands

@brianhuster

This comment was marked as resolved.

@zeertzjq
Copy link
Member

<C-W> is commonly used in shells to delete a word. If there is a Terminal mode mapping that starts with <C-W>, one will have wait 'timeoutlen' after typing <C-W> for the word to be actually deleted, which is a degrade in user experience.

@brianhuster

This comment was marked as resolved.

@ranjithshegde
Copy link

Not a core contributor so I dont know if my opinion counts for anything.

I request to please not map things to Alt as default. Alt+[key] can and will conflict with many OS/desktop-environment/Window-manager defaults for many of us. Having to unmap new nvim defaults for just this reason is a bit much.
Besides Alt is just one of those avaiilable global keys, has nothing to do with window pattern such as C-w prepend.

Also, while its true that most people map the terminal mode keys to something of their choosing, why not just let it be example in docs and/or suggested minimal_init.lua, why enforce it?

@justinmk
Copy link
Member

justinmk commented Apr 29, 2025

Alt+[key] can and will conflict with many OS/desktop-environment/Window-manager defaults for many of us

Why aren't you using super ("Windows" key) for that? It is a good choice for that.

We need a common chord prefix for window-related commands. There are many more similar commands that could use this common chord, such as ALT-n for :enew, ALT-t for a new tab, etc.

Having to unmap new nvim defaults for just this reason is a bit much.

To unblock this, I'm in favor of some sort of option like g:default_mappings, or even a command like g<BS> (for the nvim --clean case). It's that important. We can't be blocked on this decision for eternity.

@ranjithshegde

This comment was marked as resolved.

@miroshQa

This comment was marked as resolved.

@brianhuster
Copy link
Contributor

brianhuster commented Apr 29, 2025

Alt + key is a very common mapping for tiling window managers. It’s also used for many keymaps in Zellij. And I personally use it as a prefix for keymaps in my terminal emulator.

I think that's only a problem if you run Zellij inside Nvim terminal? If you run Nvim inside Zellij, key sequences have to go through Zellij first, don't they?

To unblock this, I'm in favor of some sort of option like g:default_mappings, or even a command like g (for the nvim --clean case). It's that important. We can't be blocked on this decision for eternity.

What about <Plug>(nvim-window-prefix) (or just <Plug>(nvim-window))? For example, if users only want all those window-related mappings for normal and insert mode, but not terminal mode, they just need to run ONE line of Lua

vim.keymap.set({ 'n', 'i' }, '<M-w>', '<Plug>(nvim-window-prefix)')

instead of setting g:nvim_window_map and then run N lines of Lua/Vimscript to unmap N mappings for Terminal mode.

@erikbloodshed
Copy link

Saying + HJKL is "not ergonomic" is like saying something is overrated. That key combo has been the standard since the dinosaurs use Vim. It’s part of the Vim tradition: consistent, easy to remember, and extremely well-documented.

@gpanders
Copy link
Member

Alt + key is a very common mapping for tiling window managers. It’s also used for many keymaps in Zellij. And I personally use it as a prefix for keymaps in my terminal emulator. Adding those keymaps by default will cause a lot of conflicts with user environment keymaps for no benefit

Your window manager, terminal emulator, and Zellij will all "see" the key presses before Neovim ever does, so you wouldn't need to unmap anything. The Alt prefixed key sequence would only reach Neovim if it wasn't first consumed by another application.

@miroshQa
Copy link

miroshQa commented Apr 29, 2025

Alt + key is a very common mapping for tiling window managers. It’s also used for many keymaps in Zellij. And I personally use it as a prefix for keymaps in my terminal emulator. Adding those keymaps by default will cause a lot of conflicts with user environment keymaps for no benefit

Your window manager, terminal emulator, and Zellij will all "see" the key presses before Neovim ever does, so you wouldn't need to unmap anything. The Alt prefixed key sequence would only reach Neovim if it wasn't first consumed by another application.

Didn't think about this, so it isn’t a big deal then.
But anyway, what problem would adding those keymaps as default solve? Four fewer lines of code for the user?

@justinmk
Copy link
Member

But anyway, what problem would adding those keymaps as default solve? Four fewer lines of code for the user?

It opens up an entire set of window/layout-related keymappings, like I already mentioned. There are 10-15 mappings that I will propose, probably more.

@justinmk
Copy link
Member

justinmk commented Apr 29, 2025

Your window manager, terminal emulator, and Zellij will all "see" the key presses before Neovim ever does

So that objection is unblocked.

And as @brianhuster mentioned, defining these with a <Plug>(nvim-win) prefix is a low-cost way to let users opt-out, or to allow us to revert by changing 1 line later.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
defaults Nvim defaults for options, colorscheme/theme, autocmds/events, etc.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants