Add syntax highlighting for project symbol search by da-r-k · Pull Request #188 · zed-extensions/java

da-r-k · 2026-02-09T09:25:45Z

Summary

Implements label_for_symbol to provide syntax-highlighted labels in the project symbol picker (cmd-t). Currently, Java symbols appear as plain grey text with no highlighting, unlike Rust and other languages that already implement this.

Ref: zed-industries/zed#36383, zed-industries/zed#37176

Changes

Add label_for_symbol to the Extension for Java impl
Import Symbol and SymbolKind from the extension API
Generate Tree-sitter-parseable code snippets for each symbol kind so the Java grammar produces correct AST nodes and syntax highlighting
Wrap member-level constructs (methods, fields, constructors) inside class _ { } since Java's Tree-sitter grammar requires class context for these declarations
Display symbols in Java declaration order (type before name): void doWork(String, int), String fieldName
Show keyword prefixes for type declarations: class, interface, enum, package

Supported symbol kinds

Kind	Display example	Tree-sitter context
Class	`class MyClass`	`class MyClass {}`
Interface	`interface Runnable`	`interface Runnable {}`
Enum	`enum Status`	`enum Status {}`
Constructor	`MyClass(String, int)`	`class MyClass { MyClass() {} }`
Method	`void doWork(String, int)`	`class _ { void doWork() {} }`
Field	`String name`	`class _ { String name; }`
Constant	`MAX_SIZE`	`class _ { static final int MAX_SIZE; }`
EnumMember	`ACTIVE`	`enum _ { ACTIVE }`
Variable	`count`	`class _ { int count; }`
Package	`package com.example`	`package com.example;`

Screenshot:

cla-bot · 2026-02-09T09:25:49Z

We require contributors to sign our Contributor License Agreement, and we don't have @da-r-k on file. You can sign our CLA at https://zed.dev/cla. Once you've signed, post a comment here that says '@cla-bot check'.

da-r-k · 2026-02-09T09:27:11Z

@cla-bot check

cla-bot · 2026-02-09T09:27:15Z

We require contributors to sign our Contributor License Agreement, and we don't have @da-r-k on file. You can sign our CLA at https://zed.dev/cla. Once you've signed, post a comment here that says '@cla-bot check'.

cla-bot · 2026-02-09T09:27:16Z

The cla-bot has been summoned, and re-checked this pull request!

da-r-k · 2026-02-09T09:29:33Z

@cla-bot check

cla-bot · 2026-02-09T09:29:38Z

The cla-bot has been summoned, and re-checked this pull request!

tartarughina · 2026-02-09T15:24:26Z

Thanks for the PR.

Please format the code with

cargo fmt --all

and push another commit

tartarughina · 2026-02-09T16:01:56Z

@da-r-k I've tried the extension but it doesn't seem to be working as intended.

For example, when searching for the symbol Media, see snippet below, I was just getting Media in the list without any of the additional information about it

@EqualsAndHashCode
public abstract class Media {

    public static final EmptyMedia EMPTY = new EmptyMedia();

}

Are these changes depending on a change to the grammar?

da-r-k · 2026-02-09T18:12:29Z

@tartarughina

Works for me as expected. The highlighting is based on the LSP response (SymbolKind). Could you check once if you built the correct branch?

tartarughina · 2026-02-09T18:43:30Z

@da-r-k@da-r-k, I’ve been using the wrong branch. I assumed gh would have retrieved the correct one, but apparently, it wasn’t the case.
I can now see the changes.

Is fuzzy search something that the LSP needs to support to be used or is it up to us to enable it?

da-r-k · 2026-02-09T19:22:53Z

@tartarughina Yes. JDTLS uses CamelCase fuzzy search. So if you search for EmpMe it would return EmptyMedia as one of the results. It works like the regex Emp*Me*

tartarughina · 2026-02-09T21:23:00Z

@da-r-k interesting, I didn't know that it was using CamelCase fuzzy. Since that might be new to a lot, do you mind adding a small entry in the README explaining how project symbol works?

The main points would be:

the LSP offers it
fuzzy search is available but it expects CamelCase queries

tartarughina · 2026-02-09T21:31:45Z

src/java.rs

+            SymbolKind::Class => {
+                // code: "class Name {}" → Tree-sitter: class_declaration
+                // display: "class Name"
+                let keyword = "class ";
+                let code = format!("{keyword}{name} {{}}");
+
+                Some(CodeLabel {
+                    spans: vec![CodeLabelSpan::code_range(0..keyword.len() + name.len())],
+                    filter_range: (keyword.len()..keyword.len() + name.len()).into(),
+                    code,
+                })
+            }
+            SymbolKind::Interface => {
+                let keyword = "interface ";
+                let code = format!("{keyword}{name} {{}}");
+
+                Some(CodeLabel {
+                    spans: vec![CodeLabelSpan::code_range(0..keyword.len() + name.len())],
+                    filter_range: (keyword.len()..keyword.len() + name.len()).into(),
+                    code,
+                })
+            }
+            SymbolKind::Enum => {
+                let keyword = "enum ";
+                let code = format!("{keyword}{name} {{}}");
+
+                Some(CodeLabel {
+                    spans: vec![CodeLabelSpan::code_range(0..keyword.len() + name.len())],
+                    filter_range: (keyword.len()..keyword.len() + name.len()).into(),
+                    code,
+                })


This code is pretty much the same if not for the keyword, cannot we simplify it removing repeated code?

Done — combined Class/Interface/Enum into a single match arm with an inner match for the keyword.

tartarughina · 2026-02-09T21:37:29Z

src/java.rs

+                    })
+                } else {
+                    // No type info, just show the name
+                    let class_open = "class _ { int ";


Why does it default to int?

tartarughina · 2026-02-09T21:38:25Z

src/java.rs

+            }
+            SymbolKind::Constant => {
+                // Wrap in class; ALL_CAPS names get @constant from highlights.scm regex
+                let class_open = "class _ { static final int ";


Why using int?

tartarughina · 2026-02-09T21:38:46Z

src/java.rs

+                })
+            }
+            SymbolKind::Variable => {
+                let class_open = "class _ { int ";


Same comment as above regarding int usage

da-r-k · 2026-02-19T04:57:18Z

@tartarughina We do not get a type info from the LSP. That's why I used int. Anyways, JDTLS does not support variables in the workspace/symbols call. It only supports methods and classes afaik

tartarughina · 2026-02-19T09:45:59Z

@da-r-k if the type is not returned then let's avoid defaulting to int. Also, if the LSP only supports methods and classes let's clean up unused code

Implement `label_for_symbol` to provide syntax-highlighted labels in the project symbol picker (cmd-t). Without this, Java symbols appear as plain grey text. Each symbol kind generates a Tree-sitter-parseable code snippet wrapped in the appropriate context (e.g. methods/fields inside `class _ { }`) so the Java grammar can produce correct AST nodes for highlighting. Supported symbols: - Class, Interface, Enum: keyword prefix + name - Method/Function: return type + name + params (Java declaration order) - Constructor: name + params - Field/Property: type + name (Java declaration order) - Constant, EnumMember, Variable: highlighted name - Package/Module/Namespace: keyword prefix + name Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

Remove handlers for symbol kinds that JDTLS workspace/symbol never returns (Constructor, Field, Constant, EnumMember, Variable, Package). Deduplicate Class/Interface/Enum into a single match arm. Add README section documenting project symbol search and CamelCase fuzzy matching. JDTLS WorkspaceSymbolHandler only searches type names (Class, Interface, Enum, Annotation) and optionally method names when includeSourceMethodDeclarations is enabled: https://github.com/eclipse-jdtls/eclipse.jdt.ls/blob/main/org.eclipse.jdt.ls.core/src/org/eclipse/jdt/ls/core/internal/handlers/WorkspaceSymbolHandler.java Zed only calls label_for_symbol for workspace/symbol results, not textDocument/documentSymbol: https://github.com/zed-industries/zed/blob/main/crates/language_extension/src/extension_lsp_adapter.rs

cla-bot · 2026-02-23T20:48:22Z

We require contributors to sign our Contributor License Agreement, and we don't have @gitbutler-client on file. You can sign our CLA at https://zed.dev/cla. Once you've signed, post a comment here that says '@cla-bot check'.

Remove handlers for symbol kinds that JDTLS workspace/symbol never returns (Constructor, Field, Constant, EnumMember, Variable, Package). Deduplicate Class/Interface/Enum into a single match arm. Add README section documenting project symbol search and CamelCase fuzzy matching. JDTLS WorkspaceSymbolHandler only searches type names (Class, Interface, Enum, Annotation) and optionally method names when includeSourceMethodDeclarations is enabled: https://github.com/eclipse-jdtls/eclipse.jdt.ls/blob/main/org.eclipse.jdt.ls.core/src/org/eclipse/jdt/ls/core/internal/handlers/WorkspaceSymbolHandler.java Zed only calls label_for_symbol for workspace/symbol results, not textDocument/documentSymbol: https://github.com/zed-industries/zed/blob/main/crates/language_extension/src/extension_lsp_adapter.rs

da-r-k · 2026-02-23T21:01:16Z

@tartarughina cleaned up the code to only include supported symbols. The last commit message has code references for all the symbols that are supported.

tartarughina

Thanks a lot for the changes and for updating the README. Looks good to me

cla-bot bot added the cla-signed label Feb 9, 2026

tartarughina reviewed Feb 9, 2026

View reviewed changes

da-r-k and others added 3 commits February 24, 2026 02:11

style: formatted code with cargo fmt --all

a1dffd9

da-r-k force-pushed the feat/label-for-symbol branch from 195b59e to 6c04d33 Compare February 23, 2026 20:48

cla-bot bot removed the cla-signed label Feb 23, 2026

da-r-k force-pushed the feat/label-for-symbol branch from 6c04d33 to 48c4a51 Compare February 23, 2026 20:54

cla-bot bot added the cla-signed label Feb 23, 2026

tartarughina approved these changes Feb 24, 2026

View reviewed changes

tartarughina merged commit 5e372db into zed-extensions:main Feb 24, 2026
5 checks passed

Comments

Conversation

da-r-k commented Feb 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Changes

Supported symbol kinds

Screenshot:

Uh oh!

cla-bot bot commented Feb 9, 2026

Uh oh!

da-r-k commented Feb 9, 2026

Uh oh!

cla-bot bot commented Feb 9, 2026

Uh oh!

cla-bot bot commented Feb 9, 2026

Uh oh!

da-r-k commented Feb 9, 2026

Uh oh!

cla-bot bot commented Feb 9, 2026

Uh oh!

tartarughina commented Feb 9, 2026

Uh oh!

tartarughina commented Feb 9, 2026

Uh oh!

da-r-k commented Feb 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

tartarughina commented Feb 9, 2026

Uh oh!

da-r-k commented Feb 9, 2026

Uh oh!

tartarughina commented Feb 9, 2026

Uh oh!

tartarughina Feb 9, 2026

Choose a reason for hiding this comment

Uh oh!

da-r-k Feb 23, 2026

Choose a reason for hiding this comment

Uh oh!

tartarughina Feb 9, 2026

Choose a reason for hiding this comment

Uh oh!

tartarughina Feb 9, 2026

Choose a reason for hiding this comment

Uh oh!

tartarughina Feb 9, 2026

Choose a reason for hiding this comment

Uh oh!

da-r-k commented Feb 19, 2026

Uh oh!

tartarughina commented Feb 19, 2026

Uh oh!

cla-bot bot commented Feb 23, 2026

Uh oh!

da-r-k commented Feb 23, 2026

Uh oh!

tartarughina left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

da-r-k commented Feb 9, 2026 •

edited

Loading

da-r-k commented Feb 9, 2026 •

edited

Loading