Skip to content

Fakeplayers incorrectly invalid with . and + #42

Open

Description

@rx-dev

Bug report checklist:
[x] The language-mcfunction extension only provides syntax highlighting. Have you confirmed that your issue is with the syntax highlighting, and not other features such as squiggly underlines, warning indicators, and/or pop-ups?
[x] Ensure that you are able to reproduce the issue without any other datapack-related extensions enabled.
[x] Make sure you attach a screenshot to your bug report. Bug reports without a screenshot will be closed.

Describe the bug:
image
In this image, the fakeplayer, rx.EnderChest+ is marked as invalid when this is a completely valid fakeplayer name.
I've tested w/ DHP off and on, this seems like a syntax related issue

Activity

  1. self-assigned this
    on Nov 11, 2020
  2. Arcensoth commented on Nov 13, 2020

    @Arcensoth
    Owner

    It looks like this token is being categorized as an NBT path. This is a recursive structure (with braces, etc) so it's not feasible to try and back-track after it see an invalid character at the very end.

    The underlying issue is that fakeplayers are sometimes impossible to distinguish between other types of tokens. It's worth noting that the grammar does indeed check for a fakeplayer before an NBT path.

    - include: "#command.token.fakeplayer"
    - include: "#command.token.nbt_path"
    - include: "#command.token.quoted_string"
    - include: "#command.token.single_quoted_string"
    - include: "#command.token.unquoted_string"
    - include: "#command.token.unknown"

    However, to avoid ambiguity, the version-agnostic grammar specifically requires one of the symbols #$% before it assumes something is a fakeplayer:

    # various popular fakeplayer formats
    # they'd get classified as unquoted strings anyway
    fakeplayer: '([\#\$\%]{{unquoted_string_nc}})'

    So you should be able to tell the highlighter directly by appending, say, $ to the front of your fakeplayers, if it suits you.

    I'd say it's at least reasonable to expect an error to not be highlighted here, such as with an unquoted string. Not sure how to fix that quite yet though, since unquoted strings are a superset of NBT paths and must be processed afterwards.

  3. rx-dev commented on Nov 13, 2020

    @rx-dev
    Author

    I think that's reasonable, a bit unfortunate ofc. I always use $'s except for load stuff so I don't mind having the blotch of red here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

bugSomething isn't working

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions