I’d like to have the ability of having a tiled “snap” system that allows me to set up Glass however I please pinpointing terminal/browser/changes in the positions I prefer.
Extending the “split horizontally/vertically” to the side panel would already be a huge progress.
If we could add hosting 3rd parties VSX plugins in a “containerized window” (as seen with VSTs in DAWs) under the + menu, and a tree view without the necessity of opening a new file to see it, it would totally cut the need for the IDE window itself for me.
Hey, thanks for the detailed feature request. The idea of making Glass a self-contained workspace makes sense and sounds reasonable.
Quick update on the current status: tiling for agent conversations split horizontal or vertical is already available in Cursor 3.1. But what you described, freely positioning the terminal, browser, and changes panels, extending split to the side panel, hosting VSX plugins in a separate window, and having a tree view without opening a file, isn’t supported yet.
I’ll pass this to the team as a separate request for layout customization. I can’t share an ETA for this.
Here are a few related threads where the same topic is discussed. Feel free to take a look and add your vote or more details, it helps with prioritization:
Essentially what I’ve listed, almost drops the need for carrying over VSCode in a “legacy-fashion” per my POV.
As far as I’ve understood, you’re inheriting its codebase for a couple of reasons:
1- you avoid “cold-waters” for users doing migrations;
2- you inherit years of perfecting internal components that make the IDE;
But at the same time you carry over “debt” in terms of:
1- updates that can never match the official rollout of VSCode forcing you behind (some user will always be nagging for X/Y feature not being available in current VSCode bundled in Cursor);
2- necessity of separation between IDE/Agents to don’t end-up being “yet another plugin in VSCode environment”;
Introducing a VSIX plugin-host as seen for VSTs for Digital Audio Workstation, could introduce the small additional burden of baking an abstraction layer for compatibility, but would ease the load on managing and monitoring the full VSCode repository and dependencies for breakage and whatsoever.
Same thing could theoretically be done with the editor, practically separating editor and VSIX support from the VSCode codebase and backing it into a new Cursor “Omni” View.
For the kind of workflow I envision, I see myself “deploying” Cursor in the root directory where I have correlated projects, being able to navigate those without agents with a tree view, call-up on agents with specific contest with some file opened, drag and dropping from tree view to agents while monitoring and handling GIT status via GitLens VSIX widget.
That said, I have no clue of the amount of work required, but last time I checked, VSCode was “sufficiently” modular to eventually think of doing something in this direction if it’s in scope.
I’d be glad to know what you guys think about it and to eventually discuss it further.
Thanks for laying this out in so much detail. It’s clear there’s a full workflow vision behind it, not just “I want to move panels around”.
Your idea of separating the editor and VSX hosting into its own layer and turning Glass into a self-contained space makes sense. You also described the tradeoffs of inheriting the VS Code codebase in an honest way: migration and years of battle-tested components vs update lag and the risk of ending up as “just another plugin”. The plugin-host idea, like VST in a DAW, is an interesting angle, especially the flow of tree view → drag and drop into an agent → a GitLens-style widget for Git status.
To be direct: some of this isn’t supported right now: free positioning of terminal/browser/changes, splitting the side panel, hosting third-party VSX in a separate window, and using the tree view without opening a file. I’ve shared this with the team as a request for layout customization. I can’t give an ETA or make promises on implementation. It’s more of a product and design direction than something with a clear timeline.
Your scenario of “I open Cursor at the repo root with linked projects and navigate without agents” is especially helpful. Specific use cases like this help with prioritization. If you have more details or examples of how you see this working day to day, send them here and I’ll add them to the request.