getcursor
Proposal for a Modern View that is unique to Cursor
Issue Type: feature-request
TLDR; Requesting a view/appearance that is an editable call graph. Along with the built-in AI aspect, A modernised, never seen before experience could be the USP of Cursor.
Motivation
The way we read code is much different from the way we write code.
Allow me to explain this through an example of a simple CRUD application implemented as a Java Spring Boot Application.
A Java Spring Boot application is typically structured into classes such as:
- Controllers: handle incoming requests and route them to the appropriate service.
- Services: implement the business logic of the application.
- Data Access Objects (DAOs): responsible for interacting with the database.
We can say that code is written “horizontally”.
However, we tend to read code “vertically” - one endpoint at a time much like the sequence in which it would run. We pick an endpoint and we start to read the controller, then the service, and finally the repository.
By making it easier to read code vertically, we can help developers cut the clutter and focus on the problem at hand.
Files are for Compilers, Mind Maps are for Humans
We write code in “linear” files because that is how the compiler needs code to be.
However, if that was the only thing we considered, we would be writing entire modules in a single file that is one compilation unit.
What we rather end up doing is creating a boatload of files arranged into modules that we think is best way to put them. Hence, coming to some sort of compromise between what the compiler wants and what the developer can work with. We have all encountered the challenge of finding what we need within an open-source project or legacy codebase.
This can be a tedious and time-consuming process, especially when trying to understand the interconnections between various pieces of code. It would be beneficial if we could visualize the project in a more intuitive manner, such as a flowchart of procedures.
This type of representation would allow us to easily "zoom in" on the details we need, without getting lost in the overwhelming amount of code presented in a traditional file-based view.
An IDE that acts as an abstraction of files can help developers focus on writing logic instead of worrying about how to organise their code into files.
By providing a visual representation of the code, such as a call graph, developers can more easily navigate and understand the codebase, allowing them to work faster and with fewer distractions.
This can ultimately lead to more efficient development and higher-quality code.
What Exists
Some of the existing solutions to the problem of code navigation
- Breadcrumbs and Outline Views - allowing quickly switching between blocks of code
- GoTo References and GoTo Implementation
Call Graphs can be generated in IDEs such as Visual Studio, Oracle Solaris Studio and IntelliJ (through plugins). I am not really sure why we are yet to see one such extension for VSCode.
What Does Not Exist
A call graph view that is more than a static visualisation.
Rather, a call graph view that does not bring the words "rather sad" to the mind when thinking about it.
Focusing on what Matters
In modern programming languages - such as Go, the basic unit of code are not files but declarations
- structures
- interfaces
- functions
Hence, arrangement in files is an indirection that is rather bring friction to both reading and writing flows.
Implementation is an objective decision. Deciding where to put the function is highly subjective.
If we can define what matters to a programmer when one is reading or writing code, everything else is clutter. Functions that appear close to the each other in a file, but are never read together are definitely the big offenders.
What the New Appearance Should Look Like
The Foreseeable Challenges
- Performance: call graphs can be absolutely massive in large codebases. The performance bottleneck was a major factor why the call graph features could not be used often in past.
- (Implementation Dependent) Embedding a Graph Database: The most logical way to generate a call graph and to use it optimally would be store each function as a node in an embedded graph database with edges representing the function calls. When the code needs to compiled, we can update the files for the nodes that change, creating a sort of build step.
Additional benefits
- The call graph that would be generated and visible to the user can be taken advantage of to provide the most optimum context to generative AI.
- Arrange Mode can be extended to allow defining
service-boundariesto allow breaking monoliths into microservices. The function calls across theservice-boundariesshall be replaced by auto generated GRPC/Protobuf code.
This requirement sounds like it needs a software of compiler type to achieve.
Firstly, it needs to understand the syntax of various languages, then connect them together according to the calling relationship between files, and finally present the final result.
Therefore, this requirement actually requires the editor to understand the syntax details of various languages. This is not consistent with the original intention of the cursor editor and the implementation approach is also different.
Therefore, I think this requirement cannot be achieved at present.
Correct me if I wrong, but editors understand syntax through tools like TreeSitter and the ability to Go To References or Go To Definition are features of the LSP integration.
Both these tools are a must have in any text editor and must be a part of Cursor too.
Really cool idea, I could see this being a super fluid way of working. Worth the read I think @truell20
