Replies: 7 comments
-
Personally I don't like this because it waste space (I am on a 80x24 terminal). May seemed useful at times but I might still use |
Beta Was this translation helpful? Give feedback.
-
Could be something configurable. |
Beta Was this translation helpful? Give feedback.
-
As an additional argument, I find this feature almost required to make any use of the commands |
Beta Was this translation helpful? Give feedback.
-
As a bufferline implementation was merged a while ago, I'm marking this as a |
Beta Was this translation helpful? Give feedback.
-
I have implemented the command I've currently implemented it only as a normal, typed command. So no Usage: I've also refactored the "previous" / "next" buffer commands a bit, as there was some functional overlap, and a naming collision with the function I personally would love to see switching buffers using a shortcut like ctrl + <i>. That would match many other programs behaviour. For example browsers, some terminals (Windows terminal uses ctrl+alt + <i>, and iTerm 2 on MacOS cmd+<i>), Windows explorer, and probably a lot more I can't think of right now. Interestingly, VS Code choose ctrl + <i> as shortcut for pane (you call those "Windows") switching, and alt + <i> for tabs. That's probably why I've never used it there. Instead, I mainly utilized ctrl + tab (it cycles through the open editors). I would be happy to implement more functionality, but I'm not really sure if that would collide with other shortcuts, nor have I figured out how to do that yet :D. |
Beta Was this translation helpful? Give feedback.
-
Update: Added shortcut supportI've now added support for shortcuts in the previously mentioned pull request. I've gone with the combinations that I was already most familiar with (see above). |
Beta Was this translation helpful? Give feedback.
-
Hello! I've added a PR #8198 to close this issue because it has been open for a long time. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
I know I can switch buffers with space+b and then searching or moving up-and-down, but this still introduces some kind of mental cost for buffer switching, especially when you do it frequently. I also feel like a modern editor should show a list of the open files.
With (n)vim, both of these problems are solved by buftabline.nvim. It shows the open buffers in the "tabline" and allows switching to them with +buffer number. This allows fast access to the first 10 buffers, at almost no mental cost. (From experience I can tell you that once you get used to this, all other methods of buffer switching will feel excruciatingly slow.)
I know that keymappings in helix deliberately do not make use of the numbers, because they're farther away, but this isn't really an editing command, so I think it's fine in this case, though I don't know how you see this.
Beta Was this translation helpful? Give feedback.
All reactions