Performance improvement: add a lightweight parse-tree editor mode alongside full build-based semantic mode

**Summary**
Please consider adding an explicit lightweight editor mode that lets the user switch between:

* **Build truth**: current compiler/build/resolver-driven editor behavior
* **Parse-tree truth**: a lightweight incremental syntax-tree-driven editor mode for fast, structure-aware editing without requiring full semantic/build synchronization

The goal is not to weaken Eclipse’s semantic model, but to let users choose a much lighter editing path when full build truth is not needed at every moment.

**Problem**
Eclipse is still one of the most mature and professional-oriented development environments available. Its workspace model, semantic tooling, refactoring depth, and overall seriousness are still hard to match.

At the same time, newer editors such as Zed, VS Code, Vim, and Neovim have raised expectations around responsiveness, immediacy, and low-latency editing. Even when they are less mature semantically, they often feel faster, more direct, and more structurally available during the inner editing loop.

Eclipse currently tends to couple “what the editor knows” to build/compiler/index/classpath state. That is excellent when full semantic correctness is needed, but it also means the editor always behaves as though the user wants compiler-grade truth at all times.

There are many situations where that is unnecessarily heavy:

* opening or navigating very large workspaces
* editing while build state is incomplete or temporarily broken
* doing structural edits where local syntax truth is enough
* wanting a faster, lighter editing loop without abandoning Eclipse’s mature tooling model

Today the choice is effectively binary:

* keep full build truth and accept the heavier model
* disable pieces of the machinery and lose truthful IDE behavior in unclear ways

What seems to be missing is an explicit, honest middle ground.

**Proposal**
Introduce a user-visible editor mode boundary between:

### 1. Build truth mode

Current Eclipse-style semantic behavior:

* compiler/resolver/classpath aware
* accurate errors and warnings
* precise type/navigation/search/refactoring support
* full project/workspace semantic model

### 2. Parse-tree truth mode

A lighter structural mode driven by a local incremental parse tree:

* syntax coloring
* folding
* local outline / structure view
* bracket matching
* structural selection / navigation
* indentation / formatting assistance
* optionally limited local diagnostics where safe

In this mode, features requiring full build truth should be clearly downgraded, disabled, or marked stale rather than silently approximated.

**Important requirement**
The UI should clearly indicate which truth model is active.

For example:

* “Semantic/build synchronized”
* “Parse-tree mode”
* “Semantic state stale”

Without that, the editor risks becoming epistemically confusing: it may look authoritative while no longer reflecting build truth.

**Why this would matter**
This would let Eclipse preserve what it already does exceptionally well while also addressing one of the main reasons developers look with some frustration at newer editors: not because those tools are more mature, but because they often feel dramatically faster in the local editing loop.

In other words, this is not a request to make Eclipse imitate those editors wholesale. It is a request to let Eclipse borrow one of their strongest practical advantages — low-latency structural editing — without giving up its much stronger semantic and workspace-driven capabilities.

**Additional motivation**
As far as I can tell, there does not currently seem to be a mainstream, maintained Tree-sitter-style integration available for Eclipse. I could find an experimental-looking project, **ts4e**, described as a “Tree-sitter abstraction layer for Eclipse,” but it appears early-stage and does not present as a broadly adopted solution. I also could not verify a clear mainstream Eclipse Marketplace offering for general Tree-sitter integration except [https://github.com/redhat-developer/eclipseide-jdtls/](https://github.com/redhat-developer/eclipseide-jdtls/). That makes this feel less like a plugin-discovery problem and more like something Eclipse itself may need to addr([[GitHub](https://github.com/tringh/ts4e?utm_source=chatgpt.com)][1])rn680738search1turn680738search3

**Expected benefits**

* lighter editing experience in large workspaces
* faster file open / switch / local edit loop
* less dependence on full project health for basic editing usability
* more honest separation between structural knowledge and semantic knowledge
* better fit for users who want Eclipse as both an IDE and a serious editor
* a path toward some of the speed feel associated with parse-tree-first editors, without abandoning Eclipse’s mature professional toolchain model

**Non-goal**
This is not a request to remove or weaken Eclipse’s semantic model.
It is a request to make the semantic model **optional where appropriate**, instead of universally mandatory for every editing experience.

**Possible implementation direction**

* workspace, project, or editor-level mode selection
* command to temporarily switch the current editor into parse-tree mode
* automatic fallback to parse-tree mode when semantic state is unavailable
* explicit command to refresh / re-enter build truth mode

**Risks**

* users may confuse structural truth with semantic correctness
* some features may need careful gating to avoid misleading results

These risks seem manageable if the active mode is explicit and visible.

**In short**
Eclipse currently assumes that the editor should always reflect build truth. That is powerful, but not always the right performance tradeoff. It would be valuable to let users explicitly choose a lighter, parse-tree-based truth model for editing, while preserving full semantic/build truth as the high-accuracy mode.