Option to require space in inline field syntax to not clash with item::paths in programming languages

[MetaflameDragon]

Is your feature request related to a problem? Please describe.
Dataview uses the [key:: value] syntax for inline fields - however, many programming languages (such as C++ and, in my case, Rust) also use two colons for item paths. Dataview will sometimes try to parse std::vec::Vec, crate::Item or [Item::method], which is usually undesirable (and also rendered incorrectly as a result).

Concrete examples based on my notes:

• tld_kind_non_reserved[TldKind::NonReserved]@{ shape: terminal }
  • This part of a mermaid code block gets parsed by Dataview (and shows up when using =this.TldKind)
• Allow TldKind::NonReserved
  • This one seems ok - Dataview doesn't seem to try to parse this, and it gets rendered fine
• (Allow TldKind::NonReserved)
  • Adding parentheses to the previous example makes Dataview recognize and parse the item (the whole item as a key)
• (Reject TldKind::Special(_) and TldKind::Disallowed)
  • Again, parentheses cause the item to be parsed, except this time it's only "Reject TldKind: Disallowed and" as the key; the Disallowed part is not parsed
• AsRef for &str and &AsciiStr (the latter being just [std::ascii::Char])
  • I end up with a std: ascii::Char item, and it also gets rendered as if it were an inline field

Describe the solution you'd like
Adding an option to require a space after the double-colon separator would solve this issue. It feels similar to changing the prefix for inline queries, and Dataview's reference for inline fields already uses a space after the double-colon separator, as in "Basic Field:: Some random Value" or "[mood:: acceptable]".

So:

• crate::Item, (crate::Item) or ([crate::Item]) shouldn't get parsed
• crate:: Item (outside of a sentence) or [crate:: Item] should get parsed by Dataview as expected

Describe alternatives you've considered
Invalidating the double-colon syntax could be an option, but I couldn't think of a non-disruptive way to do so. Backslash escaping doesn't hide the backslash, and feels improper.

[holroy]

Is some of your examples from within code blocks, or inline code (surrounded with single backticks) ?

Have you turned on the settings for scanning for inline fields within code blocks? Could you turn that off, and would you still have examples where you use this syntax (with the buggy behaviour) ?

I can see a few references within the code related to the usage of double colons, and one of them is just a literal saying that it adds 2 characters to the count. Such hard coded values depending on the separator to be a fixed length could cause issues if we add this feature.

I'm not turning it down, but care needs to be taken before moving forward with this, or addressing this issue. But I've seen it before, and we should consider how to deal with it.

[MetaflameDragon]

Is some of your examples from within code blocks? Have you turned on the settings for scanning for inline fields within code blocks?

I could not find that option, the closest I could find was inline queries (not inline values). Toggling that option did not change the behavior.

would you still have examples where you use this syntax (with the buggy behaviour)?

I made a reduced example document with examples pulled out of my notes, and a dataviewjs table of what Dataview parses. Hope that helps!

Dataview inline field bug example.md

This is what I got on my end:

Key	Value
and `HandleKind	Disallowed`
vec	Vec
std	ascii::Char
key	value
TldKind	- NonReserved - Disallowed
"TldKind	- Special(Test)" - Special(Invalid)"
mood	acceptable
and-handlekind	Disallowed`
tldkind	- NonReserved - Disallowed - Special(Test)" - Special(Invalid)"