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.
-
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