As the title says, the schedule clear command doesn't have its relative functions resolved.

There's schedule clear which for whatever reason Mojang decided should use the brigadier:string parser and also be greedy. I suspect this is the reason for this particular subcommand.

I did a brief scan and couldn't figure out why this is happening for the schedule function subcommand. It uses the minecraft:function parser just like the function command does, and the latter works just fine. Could it have something to do with schedule function taking additional trailing arguments?

Update: schedule function works fine and I must have confused something with schedule clear in my testing.

Hello!

I tried mecha, but it seems it doesn't work with the new macro variable syntax and multiline command:

execute \
  as @e \
  at @s \
  run function $(injected_function)

Is support for such a format planned?
Thanks!

Problem

execute store result score @s smithed.data run clear @s #smithed:crafter/all 0

is converted to

execute store result score @s smithed.data run clear @s

Details

This only seems to happen when using an item tag, setting the item to something like cobblestone removes the issue

beet.yaml

name: Smithed Crafter
description: Native Library for Smithed
author: TheNuclearNexus
version: '0.0.2'

data_pack:
  name: Smithed Crafter
  load:
    - datapack
  render:
    functions:
      - smithed:*

output: out

require:
  - plugins.versioning
  - beet.contrib.dundervar

pipeline:
  - mecha

meta:
  mecha:
    keep_comments: true

Validating a datapack (e.g. pack.zip) with a place template command (e.g. place template minecraft:fossil/spine_1 ~ ~ ~) leads to the following error:

Error: Plugin "mecha.cli.validate" raised an exception.

Traceback (most recent call last):
  File "/home/user/Desktop/pack/venv/lib/python3.10/site-packages/mecha/cli.py", line 30, in validate
    mc.compile(DataPack(path=path), report=mc.diagnostics)
  File "/home/user/Desktop/pack/venv/lib/python3.10/site-packages/mecha/api.py", line 432, in compile
    compilation_unit.ast = self.parse(
  File "/home/user/Desktop/pack/venv/lib/python3.10/site-packages/mecha/api.py", line 303, in parse
    ast = delegate(parser, stream)
  File "/home/user/Desktop/pack/venv/lib/python3.10/site-packages/mecha/parse.py", line 532, in delegate
    return spec.parsers[parser](stream)
  File "/home/user/Desktop/pack/venv/lib/python3.10/site-packages/mecha/parse.py", line 573, in parse_root
    commands.append(delegate("command", stream))
  File "/home/user/Desktop/pack/venv/lib/python3.10/site-packages/mecha/parse.py", line 532, in delegate
    return spec.parsers[parser](stream)
  File "/home/user/Desktop/pack/venv/lib/python3.10/site-packages/mecha/parse.py", line 638, in parse_command
    argument = delegate("command:argument", stream)
  File "/home/user/Desktop/pack/venv/lib/python3.10/site-packages/mecha/parse.py", line 532, in delegate
    return spec.parsers[parser](stream)
  File "/home/user/Desktop/pack/venv/lib/python3.10/site-packages/mecha/parse.py", line 692, in parse_argument
    return delegate(f"command:argument:{tree.parser}", stream)
  File "/home/user/Desktop/pack/venv/lib/python3.10/site-packages/mecha/parse.py", line 530, in delegate
    raise UnrecognizedParser(parser)
mecha.parse.UnrecognizedParser: command:argument:minecraft:template_rotation

I have noticed that this does not happen if you leave out the ~ at the end (only place template minecraft:fossil/spine_1).

What the title says. Block and dust particle commands are expected to work like the rest of particles when they actually have a different syntax.

ERROR  | mecha  Expected identifier or number but got literal '~'.
       | ctm_src\data\class\functions\type\bower\aim\main_arrow.mcfunction:8:58
       |      7 |  execute at @s run particle minecraft:composter ~ ~1 ~ 0 0 0 0 2 force
       |      8 |  execute at @s run particle minecraft:dust 0 1 1 0.9 ~ ~1 ~ 0 0 0 0.01 1 force
       |        :                                                           ^

ERROR  | mecha  Identifier 'yellow_concrete' is not defined.
       | ctm_src\data\playerhp\functions\absorption\destroy.mcfunction:10:44
       |      9 |  execute at @s positioned ^ ^ ^0.25 run particle minecraft:flash ~ ~1.62 ~ 0 0 0 0 1 force
       |     10 |  execute at @s run particle minecraft:block yellow_concrete ~ ~1.62 ~ 0 0.4 0 0 30 force
       |        :                                             ^^^^^^^^^^^^^^^

ERROR  | mecha  Identifier 'minecraft' is not defined.
       | ctm_src\data\playerhp\functions\damage.mcfunction:11:44
       |     10 |  #Reproduces soul bleed effect
       |     11 |  execute at @s run particle minecraft:block minecraft:light_blue_concrete ~ ~1 ~ 0.05 0.1 0.05 0 3
       |        :                                             ^^^^^^^^^

Mecha's parser will raise an exception and halt parsing the given input when it encounters a syntax error. Although this behavior is sensible, it'll be prohibitive when efforts are made to make Mecha act as an LSP, and furthermore, returning a list of errors to any person using this library is more helpful than raising an exception and stopping.

As it is now, when Mecha encounters an error, an exception is raised which propagates upwards and terminates the entire process. Some work has to be done to make the parser:

• Error tolerant: When encountering a syntax error, the parser should be able to recover. The first and easiest option is to discard parsing the entire line when an error is found, but this means that the rest of the line will not be parsed for information that can discover further errors or aid the LSP.
  The second option is to discard the current node that is being parsed and skip tokens until the boundary of the next node is reached. This is more granular and informative than skipping lines but requires a little more work (for example, when parsing an erroneous node such as ~ # ~, would the entire node be skipped, or only the middle coordinate part?).
  Furthermore, we need a good heuristic for what constitutes a node boundary. In other words, when recovering from an error, when do we stop skipping tokens to try to parse a node? Attempting to resume parsing in the middle of another piece of malformed text will only yield more errors and this can cascade to very poor error recovery.

• Error information: This one is simpler - we just need every error to include what exactly went wrong, as well as where it occurred in the source. An LSP would use this information highlight errors.

This version replaced the /placefeature command with /place <structure | feature | jigsaw> <input> [coords], and replaces /locatebiome and /locate with /locate <structure | poi | biome> <input>. Would love it as I'm thinking about changing to use beet with datapack/resourcepack development, and use the check-commands GitHub action in my CI :P