What Your Mouse Buttons Could Be Doing While You Reach for the Keyboard?

If you just bought a multi-button mouse expecting an instant productivity upgrade, I need to save you a day of frustration.

Plugging it in does nothing special. The extra buttons work. They navigate forward and back in your browser, same as every mouse has done since the early 2000s. The hardware is physically capable of so much more, but without the right software telling it what to do, you paid for buttons you will never actually use.

Think of it like buying a flagship phone but disabling Bluetooth, NFC, and the fingerprint sensor because setup seemed annoying. The hardware is sitting right there. You are just not accessing it. A month later, you have a 15,000-rupee device doing exactly what a 3,000-rupee one would.

That is the problem I ran into. Here is how I solved it.

The Hardware Was Fine. The Software Was Not.

My new mouse had 6 buttons and exactly zero dedicated software. The manufacturer's driver page had not been updated in years, and it installed a bloated application that let me assign exactly two custom actions.

I found X Mouse Button Control next. It is a free, open-source Windows utility for remapping mouse buttons, and it genuinely works. I remapped things. It felt better.

But every time I needed Ctrl+C or Alt+Tab, I still reached for the keyboard. The buttons were remapped to fixed shortcuts. Pressing the side button always pasted, even when I was in the browser and had not selected anything. Pressing it always went back, even when I was in the middle of editing a file.

Static remapping is just moving the problem. I wanted the mouse to make decisions.

Enter AutoHotkey

More searching eventually led me to AutoHotkey, an open-source scripting language built for Windows automation. AHK does not just remap buttons. It lets you write actual logic.

You might be thinking, "Why not just use keyboard shortcuts for everything?"

Because shortcuts require your hand to leave the mouse. When you are 80% mouse-driven, reviewing a pull request, reading docs, watching a video, every keyboard trip is an interruption. The goal is to keep one hand on the mouse and not move it.

With AHK, I could say: if I press this button and I am inside VS Code, paste. If I press it in Chrome, go back. If I press it while hovering over a text field in any other app, it also pastes. One button. Three decisions. Zero keyboard.

That one idea turned into a 200-line script called SuperMouse.ahk. It compiles into a 1MB .exe that runs silently at startup. I cannot imagine my workflow without it now.

What the Script Actually Does

Side buttons (context-aware):

• Side top click (in editor) -> Copy
• Side top click (in browser, text selected) -> Copy
• Side top click (in browser, nothing selected) -> Browser Forward
• Side bottom click (in editor) -> Paste
• Side bottom click (elsewhere) -> Browser Back

Side button + mouse flick (bottom button):

• Bottom hold + flick right -> Switch Apps (Alt+Tab)
• Bottom hold + flick left -> Switch Apps Backwards (Alt+Shift+Tab)
• Bottom hold + flick up -> Task View (Win+Tab)
• Bottom hold + flick down -> Show Desktop (Win+D)

Side button + mouse flick (top button):

• Top hold + flick right -> Next Virtual Desktop
• Top hold + flick left -> Previous Virtual Desktop
• Top hold + flick up -> Task View (Win+Tab)
• Top hold + flick down -> Show Desktop (Win+D)

Side button + scroll wheel:

• Bottom hold + scroll up/down -> Horizontal Scroll (left/right)
• Top hold + scroll up -> Volume Up
• Top hold + scroll down -> Volume Down

Side button long press (300ms, non-editor windows):

• Bottom hold (no movement) -> Rewind (Left arrow repeating)
• Top hold (no movement) -> Fast Forward (Right arrow repeating)

Right-click combos:

• Right click + Left click -> Show Desktop (Win+D)
• Right click + Scroll up -> Zoom In (Ctrl+Scroll)
• Right click + Scroll down -> Zoom Out (Ctrl+Scroll)

Middle-click combos:

• Middle click + Left click -> Enter
• Middle click + Right click -> Select All (Ctrl+A)

Sounds like a lot of behaviour from one script, right? The reason it works cleanly is the core function on which the whole thing is built.

The Real Engineering Part

The entire script depends on one function: IsEditing().

autohotkey

IsEditing() {
    ; 1. Check if we are in a dedicated Editor app
    if WinActive("ahk_group Editors")
        return true

    ; 2. Check for Text Select Cursor (IBeam)
    if (A_Cursor = "IBeam")
        return true

    ; 3. Check for a blinking Caret (insertion point)
    if CaretGetPos(&x, &y)
        return true

    return false
}

Before every button action, the script calls this function. If it returns true, the button does the editing action. If false, it does the navigation action.

The Editors group is defined at the top of the script: VS Code, Notepad, Word, Obsidian, IntelliJ IDEA, Windows Terminal, CMD, PowerShell, Git Bash, and Warp. If any of those processes own the active window, IsEditing() returns true instantly.

The cursor check (A_Cursor = "IBeam") catches everything else. When your mouse hovers over any text input field anywhere, the cursor shape changes to the text-edit IBeam at the OS level. AHK reads that state directly; no window class matching required.

CaretGetPos() is the final fallback. It checks whether Windows reports an active text insertion point. Some inputs show the IBeam but have no caret. Some have a caret but use a custom cursor. The three checks together handle essentially every text input situation the script has ever encountered in production.

autohotkey

; Gesture detection polling loop
while GetKeyState("XButton1", "P") {
    if SideButtonScrolled {
        Skipped := true
        Sleep 10
        continue
    }

    MouseGetPos &currentX, &currentY
    diffX := currentX - startX
    diffY := currentY - startY

    if (Abs(diffX) > Threshold || Abs(diffY) > Threshold) {
        GestureTriggered := true
        ; Fire the appropriate gesture direction...
    }
    Sleep 10
}

The gesture system records the mouse position when you press the button and enters a polling loop that checks the position every 10 milliseconds. If the mouse moves more than 50 pixels in any direction before you release the button, the gesture fires and a flag marks the click action as skipped. If you release quickly without moving, the loop exits and falls through to the click behaviour.

The #HotIf directive handles scroll interception. When XButton1 is physically held down, AHK activates conditional hotkeys that intercept WheelUp and WheelDown and convert them to horizontal scroll events. When you release the button, those hotkeys deactivate. Normal scrolling resumes with zero interference.

The Catch

This script is built for developer workflows. It is not a universal tool.

The 50-pixel gesture threshold is calibrated for my mouse sensitivity. With a higher DPI setting or faster pointer speed, gestures might fire when you meant to click. You can find the threshold as a constant at the top of each button section and change it yourself, but it does require manual tuning per setup.

The Editors group is also hardcoded. If you use a terminal or editor not on the list, you need to add it. The script has no way to auto-detect unknown applications.

Let me share a very interesting problem I faced where the right-click combo initially broke context menus completely. The problem was that AHK was evaluating every right-click for combo behaviour before passing it through. The fix was using AHK's modifier approach, so right-click only triggers Win+D if you also click left before releasing. Release right-click alone, and it passes through as a normal click. Without that ordering logic, the context menu appeared unreliably on every right-click, and the script was unusable.

The .exe also gets flagged by some antivirus tools and browser warnings. That is a code-signing issue, not a safety one. The full source is public in the gist. You can read every line before you compile.

Want to Try It?

The gist with the full script is here: https://gist.github.com/Kishan-Agarwal-28/f8c15a2bd47c82ab7e340c31fb5ce378

If you do not want to compile it yourself, the download link for the pre-compiled .exe is in the comments of the gist. Drop it into your Windows startup folder, and it runs silently on every boot.

DIY: Build It Yourself

Installing and compiling take about five minutes.

1. Install AutoHotkey v2.0 from autohotkey.com.
2. Download SuperMouse.ahk from the gist.
3. Right-click the .ahk file and choose "Compile Script." This produces a standalone .exe with no runtime dependency.
4. Press Win+R, type shell:startup, and drop the .exe into that folder. Windows runs it every login.

To add your own editor or terminal to the Editors group, open the .ahk file and look for the GroupAdd lines at the top:

autohotkey

GroupAdd "Editors", "ahk_exe Code.exe"             ; VS Code
GroupAdd "Editors", "ahk_exe WindowsTerminal.exe"  ; Terminal
GroupAdd "Editors", "ahk_exe idea64.exe"            ; IntelliJ

The value after ahk_exe is the process executable name. Find it by opening Task Manager, right-clicking your process, and selecting "Go to file location." Add your app, save, compile again, and replace the old .exe in the startup folder.

Try it yourself! It is one thing to read about mouse button remapping, but it is a whole different feeling when you paste a code snippet from the documentation using only your thumb.

Software Is the API for Your Hardware

Every device you own has capabilities sitting dormant because nobody wrote the code to expose them. Sometimes that software already exists. Sometimes you write it yourself.

A 6-button mouse is not special hardware. What makes it special is the 200-line script that took an afternoon to write and a few weeks to tune. The hardware was always there. The software is what made it real.

Happy Exploration!