Hi <@U07F861EZRQ> <@U08RTUTPL0Y> <@U04CH5304CX> <@...

# gsoc-kotlin-lsp-project

[hemram]

Hi @Shauvik Roy Choudhary @Andrew Vasilyev @Matthew Ramotar @Ryan Ulep @jbarr @Claudia Babescu
As discussed in the call, I just wanted to check in about the expectations for the first evaluation.

Could you clarify what scope or features you’d like to see completed by then? That would help me pace the work and focus on what matters most.

[Andrew Vasilyev]

Hi! I can immediately share this draft:

## **In Scope for MVP**

This section outlines the core features necessary for the Minimum Viable Product.

### **1. Project Handling**
* **User Scenario**: A user can open a Kotlin project and have it indexed.
* **Feature**: Folder-based project model (single-module, Kotlin-only), integrated with VSCode's file change monitoring.
* **Why it's in the MVP**: This provides the foundational project model and bootstraps the Analysis API and its caches.

### **2. Semantic Highlighting**
* **User Scenario**: A user can read code with semantic highlighting, where types and variable references have different colors. The highlighting updates correctly while and after typing.
* **Feature**: Semantic Highlighting.
* **Why it's in the MVP**: This implements the basic stages of syntax and semantic analysis and establishes the document markup model.

### **3. Error Highlighting**
* **User Scenario**: A user can see syntax and type-checking errors in the editor, which update in real-time as they type.
* **Feature**: Real-time error highlighting.
* **Why it's in the MVP**: This is a fundamental feature for code analysis, sharing its foundation with semantic highlighting.
* **Note**: A "solution-wide analysis" (SWEA) to provide a "whole project problems view" could be considered an additional task, but it is not essential for the MVP.

### **4. Navigation: Go to Symbol & Declaration**
* **User Scenario**:
    1.  A user presses `Ctrl+Shift+P`, types part of a symbol's name, and presses `Enter`. VSCode opens the correct file and moves the cursor to the symbol's declaration.
    2.  A user `Ctrl+Clicks` a reference in the code. VSCode navigates to the symbol's declaration.
* **Feature**: Go to Symbol & Navigate to Declaration.
* **Why it's in the MVP**: These are base navigation functionalities essential for any modern editor. The implementation will rely on the reference resolve stage.
* **TODO**: Check if the Analysis API already provides a scoped symbols cache.

### **5. Code Completion**
* **User Scenario**: A user types `.` after a variable or object and presses `Ctrl+Space`. VSCode shows a popup with a list of relevant completion variants, filtered by scope and qualifier.
* **Feature**: Heuristic- and scope-based code completion.
* **Why it's in the MVP**: This is a core code assistance feature that improves development speed. Its implementation leverages scopes, the symbol cache, and reference resolution.

### **6. Find Usages**
* **User Scenario**: A user places the cursor on a symbol, presses `Shift+F12`, and VSCode displays a list of all the symbol's references, allowing navigation to any of them.
* **Feature**: Find references/usages.
* **Why it's in the MVP**: This is a fundamental code navigation and inspection tool.

### **7. Code Actions**
* **User Scenario**: A user presses `Ctrl+.` on an error or a symbol. VSCode opens a popup with available context actions (quick fixes) that can be executed.
* **Feature**: Basic support for Code Actions.
* **Why it's in the MVP**: This showcases the server's ability to perform code modifications and provides a foundation for future quick fixes, suggestions, and refactorings.

### **8. Rename Refactoring**
* **User Scenario**: A user presses `F2` on a symbol, types a new name, and presses `Enter`. The symbol's declaration and all of its usages are renamed throughout the codebase.
* **Feature**: "Rename" refactoring.
* **Why it's in the MVP**: This is the most fundamental refactoring and is expected from any LSP implementation. If we can implement this, we can implement other refactorings in the future.

### **9. Build & Run**
* **User Scenario**: A user can configure their project, add JAR and classpath dependencies, and then build and run the project directly from the editor.
* **Feature**: Run Configurations.
* **Why it's in the MVP**: This allows users to execute their projects, providing a stepping stone for debugger support.

### **10. Debugger Integration**
* **User Scenario**: A user can debug their code, view stack frames and local variables, and evaluate expressions.
* **Feature**: Debugger Integration.
* **Why it's in the MVP**: This is an expected feature for a complete development experience. Since Kotlin uses the Java debugger, we can likely adapt an existing open-source implementation.

### **11. GitHub Copilot Integration**
* **User Scenario**: A user can leverage GitHub Copilot, which correctly understands the Kotlin project and code context provided by the language server.
* **Feature**: GitHub Copilot Integration.
* **Why it's in the MVP**: This demonstrates compatibility with modern, AI-driven development tools.

***

## **Out of Scope for MVP**

The following features will not be included in the initial MVP to simplify the scope and focus on core functionality.

### **1. Code Formatting**
* **Reason for Exclusion**: This can be handled by an external tool (e.g., `ktlint`) in the initial stages to save development time.

### **2. Java Source Code Support**
* **Reason for Exclusion**: Focusing on Kotlin-only projects simplifies the initial scope.

### **3. Multi-project & Multi-module Configurations**
* **Reason for Exclusion**: Not required for the initial language server and simplifies the project model significantly.

### **4. Inlay Hints & Code Lenses**
* **Reason for Exclusion**: These are non-essential "nice-to-have" features that can be added later.

### **5. Advanced Refactorings**
* **Reason for Exclusion**: The LSP has limited UI capabilities for complex refactorings. We will focus on the foundational "Rename" for the MVP.

### **6. "Generate from Usage" Features**
* **Reason for Exclusion**: This is a complex code generation feature that is not required for an MVP.

### **7. Complex Quick Fixes & Suggestions**
* **Reason for Exclusion**: This is a significant undertaking. For the MVP, we will only show simple, demonstrative code actions. We can consider integrating tools like Detekt or OpenRewrite in the future.

### **8. Kotlin Multiplatform (KMP) Support**
* **Reason for Exclusion**: Proper KMP support requires complex run/debug configurations and is not necessary for the core language server functionality.

[Andrew Vasilyev]

But, this is a draft and this is for whole project and it should be revised, so I would like to ask all interested people to participate and leave their thoughts here.