Add MLIR TOC

[hockyy]

• I'm the package's author and/or maintainer.
• I have read the docs.
• I have tagged a release with a semver version number.
• My package repo has a description and a README describing what it's for and how to use it.
• My package doesn't add context menu entries. *
• My package doesn't add key bindings. **
• Any commands are available via the command palette.
• Preferences and keybindings (if any) are listed in the menu and the command palette, and open in split view.
• If my package is a syntax it doesn't also add a color scheme. ***
• I use .gitattributes to exclude files from the package: images, test files, sublime-project/workspace.

My package is MLIR TOC: a Sublime Text 4 plugin for MLIR sources. It parses section banners of the form // ----- // Title // ----- //, opens a three-pane layout (source, TOC list, focused section), jumps the cursor when you move in the TOC, refreshes on save, and assigns MLIR syntax in the section pane when a syntax named MLIR is installed.

There are no packages like it in Package Control. Existing MLIR-related entries are syntax (or unrelated tooling); none provide this TOC + section workspace.

Release: v1.0.0 (semver tag).

Note: N/A items — the package has no settings file, preferences menu, or default key bindings (users can bind mlir_toc_section_workspace / mlir_toc_section_refresh themselves; README documents Command Palette use only). Not a syntax package.

[kaste]

Hola.

An MLIR syntax package whose grammar is named MLIR is recommended for highlighting in the section pane.
[your README]

What does that mean? I quickly searched for one but didn't find any https://packages.sublimetext.io/?q=mlir

Requirements: Sublime Text 4. User packages run in Sublime’s Python 3.3 plugin

You can opt-in to python38; just create a .python-version file in the root of your package. E.g. https://github.com/sublimelsp/LSP-biome/blob/main/.python-version

[hockyy]

What does that mean?

Ah, its a community package. It's not necessary for this package https://github.com/rrbutani/sublime-mlir-syntax/, that's why I just say it's recommended

You can opt-in to python38; just create a .python-version file in the root of your package. E.g. https://github.com/sublimelsp/LSP-biome/blob/main/.python-version

updated

[kaste]

I see that you now just copied the syntax without proper attribution (https://github.com/rrbutani/sublime-mlir-syntax/blob/main/LICENSE). You don't have a LICENSE file.

Do you know why the syntax isn't registered here? Or is it and I just don't find it?

FWIW

Requirements: Sublime Text 4. User packages run in Sublime’s Python 3.3 plugin host on stable builds, so this plugin avoids Python 3.6+ syntax (e.g. no f-strings). It uses sublime.list_syntaxes() / View.assign_syntax().
For local development (editors, tooling, or any scripts you run outside Sublime), Python 3.8 is pinned in .python-version for pyenv, asdf, and similar tools. That does not change the runtime inside Sublime Text.

The plugin runs python38 now. Maybe delete the paragraphs.

Otherwise looks good.

[hockyy]

Do you know why the syntax isn't registered here? Or is it and I just don't find it?

I think it's never been submitted to the repo

[hockyy]

hockyy/mlir-toc@8b3891f
@kaste

[kaste]

@braver LGTM!

[github-actions]

Package Review

Channel Diff

Removed (none), changed (none), added MLIR TOC.

Review for MLIR TOC main-8b3891f-2026.04.02.03.29.26

2 notices:
- Common used command prefix is: mlir_toc_section.
- Latest version 1.0.0 is 5 commits behind tip of main.
    Repository: https://github.com/hockyy/mlir-toc

No failures

No warnings


For more details on the report messages (for example how to resolve them), go to:
https://github.com/packagecontrol/st_package_reviewer/wiki

[braver]

Your top-level scope is source.mlir so all your scopes should end with .mlir so they can be targeted by packages. You're typically looking for increasing specificity. See https://www.sublimetext.com/docs/scope_naming.html:

Scopes are dotted strings, specified from least-to-most specific

So entity.name.function.mlir means: the name, of a function, in the mlir language.

So something like .affineStructures goes before .mlir: the name of a function that is an affineStructure for mlir. You can't get more specific than a concept in a language.

If you don't use those very custom words like affineOpsP yourself, I'd advise against using them at all. If you need them to help test or debug, have a look at using tests: https://www.sublimetext.com/docs/syntax.html#testing. They're super easy to set up and really help avoid regressions when you make changes later. If you structure your syntax well, the Show Scope Name command's popup has a Context Backtrace to help you find where the current scope is defined. This package is also super helpful while developing syntaxes: https://packages.sublimetext.io/packages/PackageDev.

[hockyy]

Your top-level scope is source.mlir so all your scopes should end with .mlir so they can be targeted by packages.

Hi thank you so much for the review @braver, just got back from my leave. Please check~

I updated some of the scopes and added testcases 5ca77b7