fix: Ignore Java annotations

[RedFlameKen]

Annotations are displayed instead of the actual method/class definitions. I noticed that #53 has been closed as well as #207. Added some @context.start fields to the queries/java/context.scm file to ignore the annotations. Also added a node there for constructor declarations. I also added a check for when the @context.start is still below the top of the screen. I'm not sure if it's the most efficient way to do it but maybe someone else can improve it.

Note: I've modified the test file for java to not treat annotations as contexts. Also, tests for php keep failing and I don't think I should modify the expected output in test/ts_context_spec.lua. Hoping someone can help fix this.

before
java:
https://github.com/user-attachments/assets/6fa66fbb-4ee6-4f46-87eb-52de651d4491

php:
https://github.com/user-attachments/assets/d9d7e4bb-4594-4809-bce8-6adfcb4ac2d3

after
java:
https://github.com/user-attachments/assets/51a16450-09d8-4ac1-bebf-e2bcbfdf1b8d

php:
https://github.com/user-attachments/assets/542a8f2f-dcd8-4c1b-8871-9e154bd100bc

[lewis6991]

Are you able to explain why this is needed?

[RedFlameKen]

that was meant to check if the row of the start of the context (@context.start) is still below the top of the screen. I got this bug after I added stuff the queries/java/context.scm:

also sorry if this is messy, it's my first time making a pull request here

[lewis6991]

This is backed up with tests so I don't mind too much if it's messy, I'd just like to understand it myself.

[RedFlameKen]

sorry for the great delay on this. From how I understand it, range[1]
is the context's start row and contexts_end_row is the top row of the current
"view". Adding @context.start in queries/java/context.scm:

(method_declaration
  type: (_) @context.start
  body: (_) @context.end
) @context

This makes it so that the return type is the start of the context of the
method.

-- lua/treesitter-context/context.lua
if parent_start_row < contexts_end_row then

This checks if the current treesitter's hovered node parent's start row (The
entire method node including annotations) is now above the top of the screen.
This however includes the modifiers node which also includes the annotations
node. Atm, I couldn't figure out how to make it check the
method_declaration's @context.start row instead of the Treesitter parent
node's start row.

so basically, parent_start_row checks if above highlighted node's start row is out of view. Normally it would display the first annotation in the context window. But I've modified the scm file to make the actual function definition line the start.

if range[1] < contexts_end_row then

This is meant to check for the actual start of the definition (@context.start).
If range[1] is still in view, do not show the context window.

[lewis6991]

can you rebase?

[Copilot]

Pull request overview

Adjusts Treesitter-context Java query captures and runtime context-selection logic so Java annotations don’t appear as the rendered context line, and adds constructor support.

Changes:

• Update queries/java/context.scm to use @context.start captures that skip leading annotation lines; add constructor_declaration support.
• Update context selection logic to avoid showing a context whose @context.start line is still visible in the window.
• Update Java language fixture to stop treating annotation lines as expected context lines.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

File	Description
test/lang/test.java	Updates expected context markers so annotations are not treated as contexts.
queries/java/context.scm	Adds @context.start to class/method declarations (skipping annotations) and adds constructor declaration matching.
lua/treesitter-context/context.lua	Adds an additional visibility check based on the final computed context range start row.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

You can also share your feedback on Copilot code review. Take the survey.

[Copilot]

get_text_for_range() calls nvim_buf_get_text, but the new visibility guard (range[1] < contexts_end_row) can skip adding the context afterwards. Since the start row doesn’t change between range0 and range, consider checking range0[1] < contexts_end_row (and/or range_is_valid(range0)) before calling get_text_for_range() to avoid unnecessary buffer reads when @context.start is still in view (e.g., hidden annotations/attributes).

[Copilot]

This adds support for constructor_declaration contexts, but there’s no corresponding fixture coverage in test/lang/test.java to ensure constructors are correctly detected (and that annotations on constructors are ignored as intended). Adding a small constructor example with // {{CONTEXT}}/// {{CURSOR}} markers would prevent regressions.