[Bug] Inline Key:: Values don't work in middle of statements

[rishifter]

I've this query in a file,

TABLE HbA1c
FROM "Daily"
WHERE HbA1c

And in two of my daily notes, I have HbA1c:: but consistently, only one of them is picked up by the query.

The value from the first file is always ignored.

Here's what I tried to fix it,

1. Copied HbA1c:: 8.1 from second file to first and it showed up.
2. Copied entire working line from second file and it showed up.
3. Matched formatting for both, the first had a divider and transcoded note below which I removed so in both files the Key:: Value is the very last thing. Still failed.

After a lot of trial and error, here's what worked: adding a period before the key:: value or putting it in a new line by itself. So,

- [[Father]] got his HbA1c:: 15.1 doesn't work.

whereas,

- [[Father]] got his. HbA1c:: 15.1 works

and

 - [[Father]] got his. 
 - HbA1c:: 15.1

works as well.

Also, if something follows the value, that is always taken as the entire value. So if I write HbA1c:: 15.1 report today, it will fetch 15.1 report today. Even if I try to delimit it using quotes like HbA1c:: "15.1" report today, it gets "15.1" report today

[blacksmithgu]

I should probably reconsider renaming "inline fields" to just "fields" and adding a separate convention for actual "inline fields" - an inline field has to be on it's own line - everything before the :: is the key, and everything after is the value.

The reason for this limitation is having an inline key in the middle of a sentence is ambigious without strong conventions: i.e., hello there:: how are you could be parsed as there -> how or hello there -> how or hello there -> how are you and so on. This gets worse with things like commas (which are used to write lists), and so on.

If you have a reasonable convention I can add it as an additional special case.

[rishifter]

Yes I understand the ambiguity that can arise from this. Is there a reason why delimiting can’t work? I think if for both keys and values, there was a requirement that they be in quotes if multi-word could solve most of it no? Either that or enclosing the entire pair inside an inline code block?

Speaking of special conventions, I happen to try this and was very pleasantly surprised that it worked. I have a lot of entries in my journal where I used the tag #watched usually followed by what, a YouTube url or a link to a movie note. So #watched:: Inception working is wonderful. The query of course needs the key watched without the #. The tags solve the problem of multi-word keys, or at least have a convention that they need underscores or dashes. In my case the entire rest of the line is useful so it’s perfect as it works now but I can definitely imagine use-cases where people might want to limit the value.

Using tags for keys this way has another advantage that this makes them more portable since I can view and search by tags in any markdown app whereas only Obsidian has the brilliant Dataview. While delimiting the entire pair using inline code could make it more readable in the middle of the line as in my example, I think hashtags could be most useful in the long run, speaking this after converting a lot of my #tags to #tags:: and noticing the ease of use already.

[blacksmithgu]

For reference, you can now use truly inline fields of the form [key:: value] to put inline values anywhere in text. They will be rendered prettily in preview mode as well.