[bug] Datacore only retrieves the first value of repeated inline fields

[tripkmin]

Hello, First of all, thank you for developing Datacore. I’ve been a heavy user of DataviewJS, and I was excited to discover the Datacore plugin—it’s a fantastic step forward. While testing various use cases, I found an issue related to how Datacore handles inline fields when multiple values are defined under the same key.

Consider the following example markdown:

asdfasdfasdf (name:: tracer), asdfasdf (name:: ash)

Using DataviewJS, this returns both values as expected:

const { file, ...rest } = dv.current()
console.log(rest)

// Output:
// { name: ["tracer", "ash"] }

However, when using Datacore, only the first occurrence is returned:

const { $infields } = dc.currentFile()
console.log($infields)

/*
{
    "name": {
        "key": "name",
        "raw": "tracer",
        "value": "tracer",
        "position": {
            "line": 0,
            "start": 13,
            "startValue": 20,
            "end": 28
        },
        "wrapping": "("
    }
}
*/

It seems that Datacore is not capturing all values when the same inline field key appears multiple times in a file.

I hope this can be addressed soon—Datacore has great potential, and resolving this would make it even more powerful. Thank you for your hard work!

[blacksmithgu]

This is currently an intentional change to align datacore closer to how the Properties / frontmatter view for files works. For multiplicity, the recommendation is to use tags instead.

Can you explain your use case for multiple inline fields with duplicate key names?

[iamrecursion]

I use this feature too, as it allows a fluent way to simply accumulate multiple valid values for a field. I use it for character work, for example, where referring to a character's name, nicknames, and so on, can all get accumulated under the "name" field.

[tripkmin]

This is currently an intentional change to align datacore closer to how the Properties / frontmatter view for files works. For multiplicity, the recommendation is to use tags instead.

Can you explain your use case for multiple inline fields with duplicate key names?

Hi again—and thanks for the follow‑up!

I use the Periodic Notes plugin to generate a fresh daily note every morning. Throughout the day I jot down my diary entries in a completely free‑form way. Whenever something feels important—an experiment to try, a key issue, a quick metric—I capture it with an inline field (key:: value). Those inline fields are then surfaced in my weekly and monthly notes to create rolled‑up dashboards.

---

Concrete English example

(try:: cold shower) — surprisingly effective for waking up.

(try:: fixed morning route → study‑café)
Maybe buy a monthly pass so I *have* to go?

Breathing exercises to reset posture.  
Walk 5 000 steps before lunch.

What DataviewJS returns

const { "try": experiments } = dv.current();
dv.list(experiments);

// → ["cold shower", "fixed morning route → study‑café"]

That array lets me:

• list all unfinished experiments on a dashboard,
• track how many new “try” items I added this week,
• feed them into a Kanban board, etc.

What Datacore returns now

const { $infields } = dc.currentFile();
console.log($infields["try"].value);
// → "cold shower"   // the second value disappears

Half the structured data is gone, so my existing dashboards break.

---

Why tags can’t replace duplicate inline fields

Need	Inline field (duplicate keys)	Tag (#)
Fits mid‑sentence without breaking prose	✅	❌
Supports multi‑word / arrow notation	✅	❌
Preserves order & allows deliberate duplicates	✅	❌
Handles numeric / emoji values (rating:: 4.5)	✅	❌

Tags are perfect for broad categories (#project/alpha), but they can’t express the fine‑grained, in‑context metadata that duplicate inline fields provide.

[nekton39]

I use inline fields as well. If you are going to go with this as a spec, I would use Vault.read myself to get the inline fields. However, Vault.read is an async function, so I probably can't use it in View. Can't you make View work with async as well?

[nekton39]

Perhaps you'd like to check out https://github.com/blacksmithgu/datacore/blob/master/src/index/types/markdown.ts field of the array instead of returning [0] in the array.

    public field(key: string): Field | undefined {
        return MarkdownPage.FIELD_DEF(this, key)? [0];
    }

This looks like a good idea, but does it cause any problems?

    public field(key: string): Field | undefined {
        return MarkdownPage.FIELD_DEF(this, key); 
    }

[lx0n2acl]

This is currently an intentional change to align datacore closer to how the Properties / frontmatter view for files works. For multiplicity, the recommendation is to use tags instead.

Can you explain your use case for multiple inline fields with duplicate key names?

Here's how I use them in a daily log:

• log:: 10:44 am: Did stuff
• log:: 1:30 pm: Took a nap
• log:: 3:54 pm: Did some work

Now that I think about it, I'm considering just using the time as an inline field and using a regex to filter them...

[lx0n2acl]

... and of course I can't have a colon in the key name 🤕

[lx0n2acl]

UPDATE: did it by extracting block elements in a bullet list instead using $elements. @blacksmithgu dude datacore is amazing

[sergeict]

Inline fields seems to be on a divergent road from "official" properties. They are an added value to DataCore and Dataview.

The question is "how to make them evolve ?"

Personally, I would opt to mainly keep the dataview way to operate since it provides while providing a few enhancements, in order to provide

• backward compatibility
• more flexibility to use fields ( i.e. incermental addition of values / multivalues at different places )
• smoother integration in fluid text.

I also note that a number of users currently benefit from the dataview feature of placing several inline fields with the same key in the same note or task. There are a number of use cases for this.

Currently, properties are attached to a note, as their parent context. DataCore adds more contexts than any other plugin : sections, blocks, lists and tasks. The parent context hence becomes more granular than ever while properties always belong to the page context.

I propose to put some effort on the inline fields per se as a valuable complement to the properties.

FEATURE REQUESTS :

1. do not drop the inline field feature, but enhance it - statement of direction -
2. allow incremental/multiple values by recursively assigning the same fiels, i.e. [field1:: value1] and further in the context [field1:: value2] should provide "value1, value2" as an answer to = this.field1 instead of the current DataCore answer "value2".
3. add controls for the above behaviours, namely (dis)allow inline fields and handle multiple assignments as multi-value or last value.

Many thanks for your valuable plugins.

[ppryamikov]

One more use case for repeated inline fields with multiple values is typed links. For example, a note can have an up:: [[Parent Note]] link for its category and multiple related:: [[Other Note]] links for related notes. It's quite an unusual way of looking at fields. Yes, we can see it as "this page has a 'related' property of type 'link'", but we can also say "this link has a 'related' type". And in the later case, multiple links on the same page should of course be able to share the same type.

One may say fields are being used non-idiomatically here, but this syntax is very convenient for this purpose (including (linkType:: [[Note]]) and [linkType:: [[Note]]] variants), and it's supported at least by the Breadcrumbs and Juggl plugins. Personally, I don't use these plugins, but I use typed links to create custom backlinks sections in the header and footer of my notes using Dataview and the Virtual Content plugin. And I can't switch to Datacore if this use case isn't supported.