How can I switch the screen my cursor is on or which the grid appears on in a multi-screen setup?

[brytonsf]

Hello. I'm liking neru so far. I use 3 monitors, and I'd like to be able to switch the screen my cursor is on and/or which the grid appears on. I haven't seen anything in the discussions or issues sections on this.

[y3owk1n]

hey there, thanks for liking neru ~ Honestly, this issue never occurs to me, as I am a single monitor person, hahaha.

Back to the question, right now how the overlay works, is that it will launch the grid overlay on top of the screen of wherever your cursor is at. I am not entirely sure if there's a need for Neru to handle the screen switching part tho, or it should be handled by window manager instead. I had an assumption that most people that uses Neru are power users and should already have some sort of window manager like aerospace or yabai workflow in term of screen / window management. Not sure about it.

TLDR. The behaviour right now is that wherever your cursor is, the overlay will be shown there. So you'll need a way to put the cursor to whichever monitor/screen you want first, before the overlay can be shown there.

Do you think this should be something coming from Neru?

[brytonsf]

It makes sense that where the cursor is, the overlay is shown. It makes sense semantically that Neru should move the cursor between screens inasmuch as Neru moves the cursor generally; otherwise I have no way to move from screen-to-screen without a mouse. It also makes sense that if the target/expected audience uses a tiling window manager that already handles this, it might not make sense to implement. I see that you've already implemented it, though :)

Personally, I use Rectangle for laying out windows (it seems to have some "move cursor across displays" option which isn't working for me) but I'll check out yabai and aerospace, esp. since you say they should already cover this, in which case I'd just use that before expecting Neru to do it.

I'm testing out the feature now, though, and it doesn't seem to work, only centers my cursor on the current screen:

local:neru/bin $ neru action move_mouse --center --monitor "DELL U2415 (1)"
move_mouse performed
local:neru/bin $ neru action move_mouse --center --monitor "DELL U2415 (2)"
move_mouse performed
local:neru/bin $ neru action move_mouse --center --monitor "Built-in Display"
move_mouse performed

These are the monitor names from settings. If I use system_profiler SPDisplaysDataType, I get slightly different names, although 2 of my monitors are named DELL U2415. (I tried both the system profiler and settings namings, neither did anything other than center the cursor on the current screen)

Either way, I'll actually be stuck with one monitor for a few days, but I mainly use multiple by default. I'll test out yabai/aerospace and see if that works. Thanks again.

[y3owk1n]

@brytonsf sometimes it doesn't report the right name to use ~ or it dont match what macOS expects. Can you inspect the daemon output instead and let me know? I am not entirely sure why it didn't work tho... so far it's working on my side..

Example:

2026-03-14T22:14:39.552+0800	INFO	app/ipc_actions.go:282	Moving mouse to center of monitor via IPC	{"monitor": "X270 240Hz", "offsetX": 0, "offsetY": 0}
2026-03-14T22:14:39.552+0800	INFO	services/action_service.go:486	Moving mouse cursor	{"x": 960, "y": 540, "clamped": false, "bypassSmooth": false, "monitor": "X270 240Hz", "offsetX": 0, "offsetY": 0}

Also i am not sure if the failure has something with desktop arrangement or not tho, if you like to, we can try to figure out.

---

Also if you can try to do neru action move_mouse --conter --monitor "whatever", it will fail and on the daemon side, it will show us what the names are expected as well ~

Also if you don't mind, you can also create a new issue, as this is very likely to be a bug.

[y3owk1n]

Actually, I might figure out the issue, you might be using the wrong daemon tho. I see you build it from source at local:neru/bin, but you have to make sure to quit the original neru first, and rerun it (both need to be run with the same build). Try:

pkill -9 neru
neru launch # or neru launch --config /path/to/your/config

then open another terminal to send the command

neru action move_mouse --center --monitor "DELL U2415 (2)"

[y3owk1n]

What i can imagine is that, we are already supporting --center flag for move_mouse action. Maybe we expand the support to monitors or screens.

Something like:

neru action move_mouse --center --monitor <monitor-name>

and then you should be able to bind it to global hotkeys and use it, or even script it. Does this make sense to your use case?

[y3owk1n]

You can track this at #578

[y3owk1n]

This is merged to main, feel free to test it out ~

[y9san9]

For some reason I should that Kyle you are a multi-monitor user, haha. That's interesting how one theoretically can fix it. By centering cursor it's possible, but you will have to manually add all your displays each time. But most of the time I think it's fine since your perfectly crafted setup implies you often work on it and not that often switch it.

But if you have 2 such setups... And you use a single mac-book for both (one at home, another at work), that might be hard

[y9san9]

I thought that you could bind shortcuts to focus on specific displays by their number of some kind

[y3owk1n]

yeap, i am just a single monitor user, never use more than 1, mostly relying on window manager to do things (yabai).

I am not sure that if we really want to put more effort in this tho, cos in my opinion, switching monitor are normally already supported by most tiling window manager (which i think most power user uses, e.g. aerospace, yabai, rift, ...). Reimplementing all of these seems like an extra thing and out of the scope.

Also i think with neru action move_mouse --center --monitor <monitor-name> command, you can easily write a script to cycle monitor and just call it via neru hotkeys or skhd or whatever else hotkey daemon that you're using.

Example:

#!/usr/bin/env bash
# cycle-monitor.sh

MONITORS=("X270 240Hz" "Built-in Retina Display")
STATE_FILE="${HOME}/.neru_monitor_cycle"

# Read current index, default to 0
if [[ -f "$STATE_FILE" ]]; then
	current=$(cat "$STATE_FILE")
else
	current=0
fi

# Cycle to next index
next=$(((current + 1) % ${#MONITORS[@]}))

# Move mouse to center of next monitor
path/to/neru action move_mouse --center --monitor "${MONITORS[$next]}"

# Save new index
echo "$next" >"$STATE_FILE"

echo "Moved to: ${MONITORS[$next]}"

then use it in wherever you like to run the bash script, e.g in neru:

[hotkeys]
"Alt+Z" = "exec bash /path/to/cycle-monitor.sh"

[y3owk1n]

or detects monitor directly without hardcoding, just an example:

#!/usr/bin/env bash

STATE_FILE="${HOME}/.neru_monitor_cycle"

# Auto-detect monitors from system
mapfile -t MONITORS < <(system_profiler SPDisplaysDataType | grep -E "^\s{8}[A-Za-z].*:$" | sed 's/://g' | sed 's/^[[:space:]]*//')

if [[ ${#MONITORS[@]} -eq 0 ]]; then
        echo "No monitors detected." >&2
        exit 1
fi

# Read current index, default to 0
current=0
if [[ -f "$STATE_FILE" ]]; then
        current=$(cat "$STATE_FILE")
fi

# Cycle to next
next=$(((current + 1) % ${#MONITORS[@]}))

# Move mouse to center of next monitor
path/to/neru action move_mouse --center --monitor "${MONITORS[$next]}"

echo "$next" >"$STATE_FILE"
echo "Moved to: ${MONITORS[$next]}"

[raphkoebraam]

I tried the proposed solution above (to use exec bash), but it ended up being a bit laggy. I took a stab at it in #704.

[y3owk1n]

Thanks for the PR for this, i have further improved it at #706. For multi monitor, the TLDR is it supports the following:

neru action move_monitor                                    # cycle next (default)
neru action move_monitor --previous                         # cycle previous
neru action move_monitor --name "DELL U2720Q"               # jump to named monitor
neru action move_monitor --name "Built-in Retina Display"   # jump to named monitor

and furthermore, you can also bind any of the action above within your mode bindings to achieve moving to different screen while your overlay is on.

[celestialdr4g0n]

Hi, thank you for the application which is better than my spoon. I think another behavior can be implemented: trigger the overlay on the current focused window. I think neru knows which window is being focued since hint mode is working. In this way user don't have to go name their monitor :). Just giving my opinion.
Again thank you for this great application.

[celestialdr4g0n]

The draw overlay on top of the monitor with the cursor still dictate. So if the current cursor and the current focused app is on different window then I don't have the overlay on the focused window. I am ok with moving my mouse to another screen using another app though.

[y3owk1n]

upon some thinking about this, i see the issue now. Your suggestion fixes a very specific workflow, but we also support showing hints on system UI like menubar and so on as well, which based on the screen of the cursor they are at. Doing your way will make it implicitly to always generate hints on the focused window, despite user might explicitly moves the cursor to another screen with an intention to click on some system UI thingy.

I am still thinking about the best way to accomodate this issue. We can discuss about potential implemenations, but I do not want to rush for a quick fix for this just yet.

Also, personally i never have this issue mainly because I am using a window tiling manager (yabai), and it provides something like mouse follow focus or something like that, and most window tiling manager now adays provides the same functionality.

I am actually in favour of explicit overlays tho, meaning that user decides where they want the overlay to show, and it should show at there. Maybe to add some primitives say action move_mouse --center --focused_window or some sort, that user should explicitly invoke it, or add it into their keybinding like Ctrl+F=["action move_mouse --center --focused_window", "hints"] to always ensure the mouse is on the focused window.

Let's discuss more, I do not want to rush for a quick fix before making sure everything make sense.

[y3owk1n]

Implemented in #765

[celestialdr4g0n]

Thank you very much

"Primary+Shift+Space" = ["action move_mouse --window", "hints"]

save my day.

[y3owk1n]

Amazing, it's also released officially under v1.35.0