Possible to use non-Rust syntax highlighter in a macro (like a nested syntax)?

[eugenesvk]

upd: ok, so this updated syntax works, but for the user to be able to update your default one (instead of copy&pasting everything and losing the ability to track your changes) you'd need to update it:

• add a tag/branch bumping the min version of ST to 4075 (and update the package manifest to allow installing the later package on the later ST)
• explicitly opt into version: 2 src

extends 4075
A string of a base syntax this syntax should inherit from. The base syntax must be specified using its package path, e.g. Packages/JavaScript/JavaScript.sublime-syntax. See Inheritance for an overview of syntax inheritance.

• split the huge statements into subgroups and then the user would be able to just copy&paste your list of sub-statements (without the code that defines them, just the names), insert his override one line above yours, and then add the two new block-lua, block-lua-body block definitions in his syntax file.

Also, if you know how to remove the need for introducing a custom syntax signifying that the } ends the lua block and not any } block inside lua (in the file above the syntax is escape: '(\})(/\*\s*lua\s*\*/)'), please share this bright idea!

Sublime Text Version

Sublime Text 4 (Build 4138)

Rust Enhanced Version

2.25.0

Operating system

OS Name macOS Catalina
Version 10.15.7

Expected behavior

Some proc macros should have all text inside them marked by a different (non-Rust) syntax similar to how nested syntaxes work, for example, in Markdown code blocks

Given that the macro names are arbitrary, but the .sublime-syntax are nested, the could the solution be a working example of a user RustEnhanced.sublime-syntax file with just a single example macro name that would have the Rust syntax completely popped/replaced by some other syntax.
Then the user would just need to change the macro name and the replacing syntax

Actual behavior

Two issues (see the code snippet below)

• do is highlighted in red as a reserved word even though it's inside a macro, so it's not Rust
• the syntax applied is still that of Rust source.rust meta.function.rust meta.block.rust meta.group.rust meta.block.rust instead of source.lua

Steps to reproduce

1. Add this snippet to a Rust file

fn lua_plugin_within_rust(lua:&Lua,_:()) -> LuaResult<()> {
  lua.load(chunk! { // ←↓ can this code be recognized as a nested Lua syntax?
    while (1 < 2) do // ← "do" this is highlighted in red as a reserved word
    end
  }
  Ok(())
}

References

#284 mentioned the macro call fix, which gave me the idea for this issue

8. Macro calls should not break highlighting on unusual tokens