In Unity, double-clicking an item in the console log will try and open it up inside Cursor, targeting the relevant file and line number.
eg, a syntax error in MySystem on line 3, double clicking it will launch Cursor, and automatically open MySystem.cs to line 3.
The first iteration of this works, but if I alt-tab back into unity, then double click the log item again, the Cursor window (on the taskbar) flashes orange, the selection cursor/carat appears in the expected position in the Cursor window, but typing doesn’t seem to show up. Its like theres some third invisble input captuiring everything.
My arguments inside Unity that tell Cursor what to open and where:
“$(ProjectPath)” -g “$(File)”:$(Line):$(Column)
Well it was using “smart quotes” in the External Scripting Editor Args, but the issue is persisting
Launching Cursor from the
Assets -> Open C# menu opens an “Untitled (Workspace)” that doesn’t ask me to save the workspace if I close the Cursor instance.
Double clicking in the console log opens two Cursor windows, Untitled (Workspace), which doesn’t ask to save if I close the window. The other window it opens is a saved workspace. So, I dont know, maybe there is some bug with how workspaces are opened, when using the Menu vs. double clicking the Console log in Unity, maybe its not a Cursor thing.
If you used VsCode before, was the same issue present there?
I installed VSCode alongside reinstalling Cursor, and it seems like it has to do more with how Unity is told which program to use.
It “picks up automatically” VSCode as an IDE, but Cursor I had to Browse to the exe to select it for Unity to know about it.
Notice the “(internal)” tag after Cursor in the list:
As a test I Brosed to VSCode as well, which gave it that (internal) tag, and the odd behaviour started showing up with VSCode as well, so:
This is a Unity or VSCode problem, not Cursor, I think.
But, if Cursor wants to mitigate the effects, see if you can work with Unity to get your IDE auto-detected in the dropdown, rather than us having to browse/enter the path to the e x ecutable, because thats what seems to drive the bug