syntax/c: highlight the header name in #include as a string, not a type by Londopy · Pull Request #4236 · micro-editor/micro

Londopy · 2026-09-20T20:25:18Z

#include <float.h> highlighted float as a type (and <, ., > as operators) because the #include line was only matched by a pattern rule, so the other top-level patterns still ran over the header name.

This makes #include lines a preproc region (like scad.yaml does), which stops the type/identifier patterns from matching inside it. The region's inner rules highlight <...> and "..." as constant.string — matching how #include "float.h" was already rendered — and keep trailing // and /* */ comments as comments. Inner rules are patterns rather than nested regions, since nested regions get top-level patterns leaked into them by highlightRegion.

Checked with pkg/highlight directly:

input	result
`#include <float.h>`	`#include`:preproc, `<float.h>`:constant.string
`#include "float.h"`	unchanged from before
`# include <stdint.h> // TODO: drop`	`<stdint.h>`:constant.string, `// TODO: drop`:comment
`#include <bool.h> /* int */`	`/* int */`:comment (`int` no longer a type)
`#include MY_HEADER`	all preproc
`float x = 1.0f;` / `int y = a < b > c;`	unchanged
`#include <float.h>` followed by `float z;`	second line still highlights `float` as type (region closes at EOL)

Closes #3930

Andriamanitra

This is a nice little improvement, works as expected.

You could remove "include" from the preproc rule on line 17 since it's now handled by the region.

…andles it

Londopy · 2026-09-20T23:14:58Z

Done! Dropped include from the pattern. While retesting I noticed that left #include_next unhighlighted (the old pattern was partially matching it), so the region start now also accepts _next.

JoeKar · 2026-09-21T15:58:54Z

The same is valid for the cpp.yaml (maybe even more like objc.yaml), right?

Andriamanitra · 2026-09-21T18:55:06Z

The same is valid for the cpp.yaml (maybe even more like objc.yaml), right?

Good point! We have syntaxes for 6 different variants of C:

arduino
c
cpp
cuda
hc
objc

It would probably make sense to use include: "c" in at least some of these to inherit from the C syntax, but I'm not sure which ones are true supersets of C. But for this PR simply copying the rule to all of them would be fine too.

Grepping for #.*include also found three others that are not C but I guess can use a similar preprocessor (I don't think we need to touch these):

ats
fortran
zscript

arduino, cpp, cuda, hc and objc had the same issue as c: the header name in an #include line was matched by the type/identifier rules (e.g. float in <float.h>). Each file keeps the group it already used for the directive (statement for arduino, special for objc) so the only visual change is the header name becoming a string. In objc the whole-line special rule for import/include is superseded by the region and has been removed.

Andriamanitra · 2026-09-21T22:19:16Z

+    - preproc: "^[[:space:]]*#[[:space:]]*(define|(un|ifn?)def|endif|el(if|se)|if|warning|error|pragma).*$"
    - preproc: "__[A-Z0-9_]*__"

-    - special: "^[[:space:]]*[#|@][[:space:]]*(import|include)[[:space:]]*[\"|<].*\\/?[>|\"][[:space:]]*$"


You accidentally removed highlighting for @import here.

Restored it verbatim in 555409f. @import Foundation; was never affected (the @(...) statement rule covers it), but @import <Foundation/Foundation.h> and @import "X.h" lost highlighting since the region only matches #. The region supersedes that rule for # lines, so it still does its job for @.

I also diffed every touched syntax file before/after over a corpus: the only lines that change now are #include/#import directives.

… identifiers Restores the whole-line special rule in objc.yaml verbatim: the region only matches the # form, so removing it dropped highlighting for @import <...> and @import "...". The region supersedes it for # lines. Also adds each file's own identifier rule inside the region, ordered before the string rule, so a macro-form include (#include MY_HEADER) keeps the identifier highlighting it had before while <...> and "..." still win.

dmaluka · 2026-09-21T22:41:55Z

works as expected.

I don't think so.

Londopy · 2026-09-21T22:52:24Z

You're right, thanks for catching it — I reproduced it with your file.

The cause turned out not to be this PR though. In highlightRegion, the region's end is located inside the region's own slice of the line, but that line-relative index is compared against the region's absolute start offset:

if start == endLoc[0] {
    searchNesting = false
}

When the two happen to be equal, every rule inside the region is skipped. #include "irq.h" hits it because start is 8 and the remaining slice "irq.h" is also 8 long — which is why the short header names in your screenshot fail and the longer ones don't.

It's pre-existing. On current master, with no changes at all, in a C file:

int a;// TODO: x    → TODO not highlighted
int ab;// TODO: x   → TODO highlighted

I've opened #4240 with the one-line fix (endLoc[0] == 0) and a regression test. With that applied, your kvm file highlights every include correctly:

#include <linux/kvm_host.h>   "#include":preproc | "<linux/kvm_host.h>":constant.string
#include "irq.h"              "#include":preproc | "\"irq.h\"":constant.string
#include "mmu.h"              "#include":preproc | "\"mmu.h\"":constant.string
...

So this PR depends on #4240 — happy to reorder them, or to hold this one until that lands.

dmaluka · 2026-09-21T23:13:52Z

@JoeKar does this problem remind your of something?

Andriamanitra · 2026-09-21T23:50:33Z

works as expected.

I don't think so.

My bad, I didn't think to test with a file where the #include lines are exactly 16 characters long! I guess this is one of the bugs fixed by #4022...

Londopy · 2026-09-22T00:04:37Z

Correction to my comment above: the fix already exists as #4022 (tracked by #4018) — I missed it and opened a duplicate, which I've now closed. #4022 has the same one-line change plus nested-region fixes.

So this PR depends on #4022 rather than anything of mine. I've offered my regression test over there since that PR has no tests and the open question was whether it breaks anything else.

This one is fine to hold until #4022 lands — no rush from my side.

JoeKar · 2026-09-22T17:40:51Z

@JoeKar does this problem remind your of something?

At the very least, we should merge #4022 (go from my side) as a temporary solution, and I need to continue working on #3127 to remove this weird (somehow self-inflicted) highlighter loop.

Yes, I know...this line was my fault and turned out to be just half of the truth. 😞

Neko-Box-Coder · 2026-09-25T00:30:58Z

+      # #include lines are a region so that the header name (e.g. <float.h>)
+      # is not matched by the type rules above
+    - special:
+        start: "^[[:space:]]*#[[:space:]]*(include(_next)?|import)\\b"
+        end: "$"
+        rules:
+            - constant.string: "<[^>]*>|\"[^\"]*\""
+            - comment: "//.*|/\\*.*?\\*/"


What's the difference between this and line 25? Other than line 25 covering @Import .... Maybe we can merge/remove one?..

Good question. With the region in place, line 25 no longer applies to any #import/#include line, since regions are matched before patterns. The only thing it still affects is @import followed by a header in angle brackets, like @import <Foundation/Foundation.h>, which isn't valid Objective-C: @import takes a module name (@import Foundation;, @import std.io;), and those are highlighted by the @(...) statement rule either way.

I diffed objc.yaml with and without line 25 over 22 valid and invalid lines. Only three change: @import <Foundation/Foundation.h>, @ import <UIKit/UIKit.h> and |import <x.h> (the [#|@] class also matches a literal |).

Merging it into the region would be worse: the region would then also take @import Foundation; and color the whole line as special.

So I think it can simply go. I restored it after the earlier review to keep the output identical for every input. @Andriamanitra, are you OK with removing it?

You're right, the @import <...> pattern matched by line 25 was never actually valid Objective-C, and @import on its own is already highlighted on line 20. It can be removed.

How about the text after @import?

Maybe change line 25 to just be matching @import ...?

Removed line 25 in 32044ff, as Andriamanitra suggested. With that, the only lines this PR changes in objc are #import/#include directives, plus the invalid @import <...> forms above.

On matching @import ... instead: the text after @import is a module name, and micro's Swift and Java syntaxes also color only the keyword there (import UIKit, import java.util.List;). That's already how @import Foundation; looks here, via line 20. (@import UIKit; does get UIKit colored, but that's the two-capitals type rule on line 10, not line 25.)

Coloring the text after @import would change how valid @import lines look, which is outside this PR's #include fix, so I'd leave that for a separate PR if it's wanted.

syntax/c: highlight the header name in #include as a string, not a type

72caeb5

Andriamanitra approved these changes Sep 20, 2026

View reviewed changes

syntax/c: drop include from the preproc pattern now that the region h…

da80c69

…andles it

Andriamanitra suggested changes Sep 21, 2026

View reviewed changes

Londopy mentioned this pull request Sep 21, 2026

highlight: apply a region's rules regardless of its start offset #4240

Closed

Londopy mentioned this pull request Sep 22, 2026

fix highlighter bugs #4022

Open

Andriamanitra mentioned this pull request Sep 23, 2026

Update nim syntax to nim 2.0+ #4237

Open

Neko-Box-Coder reviewed Sep 25, 2026

View reviewed changes

syntax/objc: remove the old import rule

32044ff

Andriamanitra approved these changes Sep 29, 2026

View reviewed changes

Conversation

Londopy commented Sep 20, 2026

Uh oh!

Andriamanitra left a comment

Choose a reason for hiding this comment

Uh oh!

Londopy commented Sep 20, 2026

Uh oh!

JoeKar commented Sep 21, 2026

Uh oh!

Andriamanitra commented Sep 21, 2026

Uh oh!

Andriamanitra Sep 21, 2026

Choose a reason for hiding this comment

Uh oh!

Londopy Sep 23, 2026

Choose a reason for hiding this comment

Uh oh!

dmaluka commented Sep 21, 2026

Uh oh!

Londopy commented Sep 21, 2026

Uh oh!

dmaluka commented Sep 21, 2026

Uh oh!

Andriamanitra commented Sep 21, 2026

Uh oh!

Londopy commented Sep 22, 2026

Uh oh!

JoeKar commented Sep 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Neko-Box-Coder Sep 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Londopy Sep 25, 2026

Choose a reason for hiding this comment

Uh oh!

Andriamanitra Sep 25, 2026

Choose a reason for hiding this comment

Uh oh!

Neko-Box-Coder Sep 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Londopy Sep 29, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

JoeKar commented Sep 22, 2026 •

edited

Loading

Neko-Box-Coder Sep 25, 2026 •

edited

Loading

Neko-Box-Coder Sep 25, 2026 •

edited

Loading