Relates to #5.

Add functions to walk through compound tag.

Should support all kinds of completions and validations for SNBT.

Sub-issues:

• #28
• #27
• #31

• #14
• #15
• #39
• #40
• #41
• #42
• #52

Please refer to https://github.com/SPGoding/datapack-language-server/wiki/IMP-Doc.

THE FOLLOWING CONTENT IS OUTDATED

Doc comments are a way to describe a function or a user-defined value for both human and DHP.

There are two types of doc comments: the one for function and the one for user-defined stuff.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

Function Doc Comments

Function doc comments MUST be put at the very beginning of a function file.

A doc comment MUST begin with #> instead of #. You MAY put several spaces ( ) or tabs (\t) before or after the beginning symbol. You SHOULD put the function's namespaced ID after this symbol. This ID can be used to perform rename operations, show call hierarchy, and many other features provided by DHP.

It's RECOMMENDED to put other comments after this line to describe the function, usage, and any other related stuff of this function, beginning with #. You MAY put several white spaces ( , \t, \r, \n, or \r\n) before or after these symbols too. Any lines that are not beginning with # (e.g. an empty line, a command, etc.) or are define comments (#define <type> <id>) will break the doc comments at that position.

You MAY use annotations which start with @ to help describe your function, showed below.

Here is an example of a function doc comment.

#> minecraft:foo
# This function is used to balabala.
# Balabala.
# Balabala.
# @author SPGoding
# @input score #foo params <description of #foo parameter>
# @input
#     score #bar params
#     <description of #bar parameter>

# But don't break the streak of `#`s. For instance, there is an empty line before this line, so this line will not be considered as part of the doc comment.

Annotations

Here's a full list of annotations that you can use within your function doc comment. All parameters in the annotation should be seperated with at least one white space. ... indicates that this argument will eat all the characters until the end of this doc comment or encounters another annotation.

Other Doc Comments

Doc comments for other user-defined stuff are similar to function doc comment, but with these differences:

• You SHOULD NOT write anything other than white spaces after the beginning #> symbol.
• Only author, deprecated, private, within, internal, public, and custom annotations work.

The doc comment MUST be write right before the corresponding stuff. Here are several working examples:

#> 
# Balalala.
# @internal
scoreboard objectives add test dummy

#> 
# Alalalab.
# @deprecated
# @within spgoding:
#define entity SPGoding

Reference: Arcensoth's IMP Function Documentation Format.

Including completions for:

• Special symbols.
  • {} for compoud tags.
  • [] for list tags.
  • [X;] for respective array tags.
  • quotes for string tags
• Compound tag keys.
• Redirect to other parsers.
• Suggestion functions.

Including insertStringNBT and insertBlockStates.

Relates to: #11.

e.g.

#region XXX
say hi
#endregion

The LineParser should provide functions to parse a whole line and show hints to users.

Provides methods to walk through nbt schemas.

Use ‘ and ’ to quote strings instead of using ``s.