Wheel: Navigation framework for Vim | Hacker News Reader

Wheel: Navigation framework for Vim

github.com

For those confused on what the navigation does and how it works, I'll try to give a basic example in desktop terms and build up.

1. If we want to switch between windows on a desktop, we use alt-tab.

2. Suppose we could arbitrarily group the windows from multiple applications into a single entity (sort of how Ubuntu defaults to grouping all terminals for application switching). For example, say we have a terminal and a web-browser in a group, and a file explorer and a web-browser in a group. We can switch between the two groups and within a group we can switch between applications.

Why do we care? If you have a large number of applications open, it's tedious to alt-tab through them all to get to the application you want. Other mechanisms exist, like ctrl+f10 for kde, but there is some economy of motion in a tree traversal vs looking at the applications, finding the one we want out of a large display of them and typing in the name of the application to bring it up. For example, if we want a particular terminal when we have 5 to switch between with 20+ other apps also running. ctrl-f10 breaks up the nice flow of alt tab and alt tab takes too long if we want to change between 5 applications rapidly.

3. Over time you may end up with a lot of groups, making navigation by group tedious. Lets introduce another level, say categories. Categories contain groups. So you can switch between Categories, within a category you can switch between groups, within groups you can switch between applications.

This plugin acts like the desktop framework above, but for files and with more features.

Did you consider allowing arbitrary tree structures? That might be easier to explain, by analogy to directory trees. Of course having fixed levels has its benefits. It reminds me a bit of the notebook/section/page hierarchy in OneNote (although OneNote also allows arbitrary subsections and subpages).

This seems like something created by a genius mind but honestly I don't want to think about topology when I'm navigating files in vim. Ctrl-P is about as fancy as I can deal with I think...

My thoughts exactly after I tried to read the readme for second time.

However, thinking a bit more about it, I simulate something like author's kind of hierarchy with vim+tmux: for each distinct activity I usually start new tmux session (e.g. frontend, backend, terraform, etc.). For each project inside the activity I usually have 1-2 tmux windows with vim opened in the root of the repo, e.g. in the backend I'd have vim with microserviceA, vim in microserviceB, vim with shared library and a shell with REPL and docker logs. So it goes tmux session -> tmux window -> file in vim. Switching files in vim within a project is a solved problem (fzf and language servers).

The downside of that is that it's not always possible to jump from a file in one vim into another within a session, I have to manually switch windows. But most of the time `gd' works if you have import paths set correctly.

Interesting workflow, the main issue I have with all this is that I use several worktree and sometimes I have to switch to a different worktree..

So I'd need something which stores relative path..

I've looked at this repo multiple times recently and can't figure out what it does. Am I missing something? Can someone help explain it?

Looks like a buffer list, i.e. a list of open files in the vein of tabs in mainstream editors, but with groups for those buffers. Visually reminds of Helm/Ivy's buffer list in Emacs. And then the whole thing got on amphetamines and the author was carried away, so now it has multilevel organization and a bunch of other features that even in Emacs are supplied by separate packages with some integration maybe.

Edit: actually it's mentioned that the author has previously written about the same thing for Emacs—borrowed from someone else but rewritten from scratch.

It seems like tree tabs in browsers, except limited to three levels.

i wish i knew about this much earlier in my vim days. there's a catch 22: on the one hand, this single plugin solves a ton of problems for the advanced vim user; on the other, advanced users have likely already stitched together a patchwork of plugins, scripts, and configs that accomplish most of this one's functionality. So a new user does not understand how this plugin is truly invaluable, but the value proposition to the experienced user is mitigated by the drastic rewrite and relearn for a potentially marginal benefit.

but if you throw the word lua in the description somewhere that'll net you a couple hundred stars from the nvim people.

edit: i am an nvim/lua person.

I don't see why you would write a plugin in VimL nowadays. I mean even VimL's author decided to just create a new language — vim9 script — instead of fixing this one [1].

With neovim rpc you can write glorious plugins in TypeScript and Python such as coc.nvim [2].

Other than that, I'm inspired by amount of work you put in the project.

[1]: https://github.com/brammool/vim9#3-better-vim-script

[2]: http://github.com/neoclide/coc.nvim

Reply on news.ycombinator.com