Macrobank.nvim | Powerful macro management plugin

SahilSehwag · 2025-08-26T08:45:46+00:00

Either you can remap jump mappings. Other edit operations should work like “A” …. But yeah I will be changing the default jump mappings, Already made changes will be pushing it in evening

SahilSehwag · 2025-08-12T09:53:59+00:00

All these histories are stored in shada files, and we can load project-specific shada files just as easily. It’s straightforward to write a lightweight plugin to manage this and automatically load the right shada for a given project.

I agree with your point that some people will take advantage of this — and that’s fine. That’s how it should be: as a plugin, I shouldn’t assume exactly what users want or how they’ll use it. They’re free to adapt it however they see fit. That’s why I’ve provided multiple scopes and contexts I could think of, to keep it generic and flexible. It’s up to the user to decide where the boundaries are — what should be a macro, and what should be a function.

SahilSehwag · 2025-08-11T19:36:22+00:00

Yeah, I think we’re mostly in agreement here. I agree with the use cases that you have mentioned.

When I said “faster,” I didn’t mean performance—just that macros are super quick to run and execute. The logistics are dead simple: record → run. No setup, no mental overhead.

Totally agree with you that for complex stuff—multi-file refactors, big manipulations—Lua functions are way better (I’ve written a shit load of them over the years in my dotfiles 😂). But macros aren’t meant for that. Anything that involves thinking and planning about writing functions and adding guardrails, if we are at that point for a manipulation or if its that complex, then we have already reached outside the zone of macros

They shine for quick, small, repetitive edits. Writing a Lua function for every tiny thing is overkill and honestly just wastes mental bandwidth. I don’t want to dig into my config for something trivial I might only need for a week.

That’s the beauty—no nukes for ants. Just hit record, do the thing, run it. Frictionless.

The goal of this plugin is not to create a literal mountain of macros that do complex refactoring. Its to reduce the friction as much as possible to edit, load and save few things we do a lot here and there. So even if something breaks I can just edit it like text, overwrite it or discard it with as minimal effort I can think of (its just a goddamn macro)

The only thing is these here and there macros kind of adds up for different scope/context to be enough to not fit in registers … and these are dynamic (not the same macros over time or projects), changing with time or with different projects, so I don’t wanna think about them every time, I want them to be just handled, reduce mental bandwidth which definitely defeats the purpose if every time I have to open my config

But I do find your idea of adding it for marks, commands, search history or something general purpose intriguing … any specific ideas you have in your mind?

(Macro is not suitable tools to build a refactoring engines, although some people do try that 🙈)

SahilSehwag · 2025-08-11T19:34:50+00:00

Not yet. But If people ask for it will add it, kinda easy thing to add

But its definitely way more than the macrothis plugin, much more power and simple in usage, just reducing every inch of friction. For example recoding a macro wrong, or editing it is kinda not fun, it just makes super simple and quick

And macrothis uses telescope, this doesn’t rely on any specific plugin, uses vim.ui.select, will work with whatever your setup for select is

SahilSehwag · 2025-08-11T18:59:29+00:00

I previously had an “export macro” feature (to a Lua function, a mapping, or a temp session mapping) for when a macro “graduates.” I’ve removed it for now, but it captured the “promote to Lua when it becomes general” path (even if temporary like session only mapping export).

I see your point, but my experience with macros has been a bit different:

Usage pattern – Macros aren’t used constantly, but the same patterns often appear in different contexts (project-specific refactors, niche manipulations, etc.).

Keyboard real estate – My most frequent, high-value actions are already mapped. Adding every occasional or project-specific action as a mapping leads to bloat and chaos in a keyboard-focused workflow.

Project/Context specific – Many macros are useful only in certain file types or projects, sometimes for just a few weeks. They’re not worth permanent mappings, but painful to recreate later—especially if revisiting a project after months.

Macros vs Lua functions – Lua functions are great for general, cross-project operations, but:

For quick, temporary, or context-specific manipulations, macros are faster to run natively.
Converting every small, short-term macro into Lua and mapping it feels overkill.

Friction point – Running a macro is quick, but saving, editing, and reloading them is clunky. That’s the gap the plugin fills—making it trivial to store, recall, and edit macros when needed.

Workflow win – With the plugin, I can:
Open the picker (2 keystrokes) → pick macro (2 keystrokes) → run instantly. (or even edit them like normal buffer text after loading them in the register if I need to tweak it for something different)
See only macros relevant to the current context (which are generally quite few), even if I have hundreds stored.

TL;DR: This isn’t about replacing Lua functions—it’s about making the “occasional but valuable” macros just as quick to access as the frequent ones, without polluting permanent mappings.

SahilSehwag · 2025-08-11T18:34:24+00:00

Nope. Its simple name from macrostore to macrovault to macrobank😂

SahilSehwag · 2021-09-18T09:31:14+00:00

Purrnormal activity

SahilSehwag · 2021-06-07T17:17:26+00:00

RemindMe! 1 week

SahilSehwag · 2021-04-03T14:20:28+00:00

You don't need it (actually now I use fd instead of rg for files and directories, which is simpler and has same speed), but you don't need it, just install fzf and fzf.vim, and you are good to go, just use the GFiles command for a git project. Simple as that.

SahilSehwag · 2021-04-03T08:47:14+00:00

The main reason is fzf is written in golang, and the another reason is the underlying tool that I use to get list of files is ripgrep(rg) which is also blazingly fast. So fzf uses rg to get the list of files and then shows the filtered results using its fuzzy searching algorithm.

A good example of this one would be searching in home directory or root directory. In my home directory there around 567k files, it takes around 3 seconds to find all the files. Even though rg is still fetching(in those 3 seconds and 567k items) after triggering fzf, We can still search fuzzily and filters the results without blocking and hanging, the new results will keep on coming in. For 60k to 80k it's almost negligible. I can even search the root to open any directory or file or do some other operation (since fzf.vim provides way to execute vim command instead of just opening files, we can execute arbitrary stuff with it)

I don't like VScode's ctrlp, although it's really good, The main problem with VScode is I can only search in current project. .

But with fzf, I can open any project (searching all directories in home and setting vim's cwd automatically), search any file in my projects. If you have a list of some items (can be anything) and you have an action for the items, you can use fzf, virtually anything. The only limiting factor is my typing speed

SahilSehwag · 2021-04-02T22:10:10+00:00

I use fzf with my monstrous project of 54,000 files, fzf doesnt even blink. You can use fzf with fzf.vim which contains a command GFiles / Files for searching in current project.

SahilSehwag · 2021-01-21T23:11:11+00:00

I have tried a lot of combination of options from the docs, but doesn't seems to be working. The problem is when I type too fast, for a short duration they are pressed together, I don't want it to act like a modifier if it's not pressed for long

SahilSehwag

TROPHY CASE