FR: Move inline yaml to front matter

[blackpeasy]

Similar to the 'move tags to yaml' rule, I would love a rule to move any inline metadata-fields to yaml.
Before:

date:: 2022-10-08

After:

---
date: 2022-10-08
---

[pjkaufman]

Thanks for putting in the request! Could you provide the formatting specs for inline metadata-fields? A link to where the format is defined would be helpful in understanding if this is feasible. I believe that it follows the format: key_name:: value. But I am not certain on this.

[sigrunixia]

Not the OP, but here is Dataview's guide on all the fields it recognizes, including Inline Fields.

Additionally if it's helpful as far as gauging the request, a common practice is to throw these inline fields into collapsible Obsidian Callouts or Admonitions to make them obtrusive.

[blackpeasy]

Not the OP, but here is Dataview's guide on all the fields it recognizes, including Inline Fields.

Additionally if it's helpful as far as gauging the request, a common practice is to throw these inline fields into collapsible Obsidian Callouts or Admonitions to make them obtrusive.

Thanks for the help. I've simply been too busy to figure this out

[Friedolito]

Until now, I stored all my metadata with a list of inline fields (key:: value) directly in the .md file.
Now with the (amazing) new properties feature in obsmd 1.4 I would like to move all of the existing metadata in to the frontmatter and be compatible with the properties manager.

I think I'm not the only one who used inline fields till now, in order to have metadata with functional links.
An automated way to move inline fields to the frontmatter could probably be a useful tool not only for me, in order to transition to the new properties manager
Obsidian linter seems to me as the right plug-in for the job.
As I see it (have no background in programming) linter had to:

• Detect inline fields (key:: value)
• Move them in to the frontmatter and change the :: to :
• wrap links in to quotation marks

It would save me (and maybe a lot of other users) a ton of time! So I would be really glad to see this feature!

Thank you so much for developing Linter for obsidian! I use it regularly and it saves me already a lot of time!

Best regards :)

[pjkaufman]

What do inline links look like? I ask because I do not see an example of what they look like.

I also see embeded inline fields. Is that covered in this request?

[sigrunixia]

Here you go.

# Header Text

Dataview-field2:: [[Image.png]]
Dataviewfield:: Some text
Here is some [DataviewField3:: Text] or [dataview-field:: [[Text]].]

[pjkaufman]

Here you go.

# Header Text

Dataview-field2:: [[Image.png]]
Dataviewfield:: Some text
Here is some [DataviewField3:: Text] or [dataview-field:: [[Text]].]

What is the expected result of moving embeded inline fileds to the YAML? Are they just removed entirely, replaced with the value of the inline field as well, or something else?

[sigrunixia]

What is the expected result of moving embeded inline fileds to the YAML? Are they just removed entirely, replaced with the value of the inline field as well, or something else?

Here is what I can think of.

Result A: Move All Inline Fields to Frontmatter (Destructive)

---
original: Pie
---

table-pie:: Cherry Pie
pie-image:: [[pie.png]]

I want to eat this [tasty-pie:: pie].

Becomes

---
original: Pie
table-pie: Cherry Pie
pie-image: "[[pie.png]]"
tasty-pie: pie
---

I want to eat this .
---

Result B: Move Inline Fields on their own line (or proceeded by a > ) into Frontmatter

---
original: Pie
---

table-pie:: Cherry Pie
pie-image:: [[pie.png]]

I want to eat this [tasty-pie:: pie].

> [!metadata]-
> icky-pie:: broccoli
>

Becomes

---
original: Pie
table-pie: Cherry Pie
pie-image: "[[pie.png]]"
tasty-pie: pie
icky-pie: broccoli
---

I want to eat this [tasty-pie:: pie].

> [!metadata]-
>

Result C: Move Inline Fields on their own line (or proceeded by a > ) into Frontmatter AND leave markdown keys alone.

---
original: Pie
---

table-pie:: Cherry Pie
pie-image:: [[pie.png]]

I want to eat this [tasty-pie:: pie].

> [!metadata]-
> icky-pie:: broccoli
>

second-pie:: [coconut](coconut-pie.png)

becomes

---
original: Pie
table-pie: Cherry Pie
pie-image: "[[pie.png]]"
tasty-pie: pie
icky-pie: broccoli
---

I want to eat this [tasty-pie:: pie].

> [!metadata]-
>

second-pie:: [coconut](coconut-pie.png)

Some Context: It became common practice to hide these inline fields in a metadata callout, because they were unsightly. However, some users, particularly those who prefer markdown style links, will still need to use the existing methods because current plans have markdown links unsupported in the frontmatter for the purposes of linking, image linking, graphs, etc.

[fetwar]

Obsidian won't update backlinks if they are within the frontmatter, linking between notes in the front matter is just asking for broken links when files are renamed in future. They'd have to be escaped anyway which is gross and they won't work in the graph view - double gross.

I've had great success using Dataview inline fields for linking, it appears on the graph, they're automatically renamed and so far I've had no issues utilising them neither from my Dataview queries, nor any of my Dataview API based plugins.

However, I haven't been able to use Obsidian Linter to extract my non-link fields into the front matter without moving my inline field links as well.

In my opinion, the poor support of links in the front matter makes for the perfect use case for new Obsidian Linter features.

Leave Links as Inline Fields

When moving inline fields to the YAML front matter, the option to specify that inline fields with links should remain in the body.

Example

---
title: planes
---
related:: [[trains]]
image:: [[plane-image.png]]
type:: vehicle
rating:: 8
rating-comment:: Flying is pretty cool

Becomes

---
title: planes
type: vehicle
rating: 8
rating-comment: Flying is pretty cool
---
related:: [[trains]]
image:: [[plane-image.png]]

Move Front Matter Links to Inline Fields

Extract currently linked fields in the front matter to inline fields in the body of the note.

This could also potentially use a metadata callout like sigrunixia mentioned, if that is what floats your boat.

---
title: planes
type: vehicle
related: "[[trains]]"
image: [[plane-image.png]]
rating: 8
rating-comment: Flying is pretty cool
---

This is some random body content about planes.

becomes

---
title: planes
type: vehicle
rating: 8
rating-comment: Flying is pretty cool
---
related:: [[trains]]
image:: [[plane-image.png]]

This is some random body content about planes.

[julesvirallinen]

Obsidian actually updates links in frontmatter after the newest update (but not on mobile yet). Here's a quick demo from my test vault

Seems to be a lot of things with this newest update that we'll have to see how plugins like this and dataview will have to adapt.

What I would do if I made a custom rule out of this one would be to extract the dataview-parsed frontmatter (includes inline), and then update that into the frontmatter, might try something like that.

[pjkaufman]

I see that you can have a space in the inline fields. How does that work when it comes to defining the key? Does it have to be inside of the parenthesis or brackets for that to be allowed?

[pjkaufman]

Also how should values being in an inline field and the frontmatter be handled? Do I just replace the value in the frontmatter with that of the inline field?

[fetwar]

I was really pleased with the new update, the biggest issue I have with it is that it can't store a list of links and still update them, at that point it treats it like a text field and the same error occurs.

So for instance this inline field works and can be interpreted as an array, despite not being correct YAML: 

related:: [[foo]], [[bar]], [[baz]]

But this frontmatter doesn't (causing some painful display bugs with Obsidian Properties) even though it's correct YAML (the previous style, doesn't work when in the frontmatter either):

---
related:
    - [[foo]]
    - [[bar]]
    - [[baz]]
---

It is a huge step in the right direction, I hope to see the functionality continue to improve.

As far as I am aware, the properties update doesn't cause any issue with Dataview because it is just a rendering of the frontmatter. So when working correctly the frontmatter is unchanged and still indexable by the Dataview API.

---

@pjkaufman
Dataview sanitises inline fields, so spaces and uppercase letters are converted to lowercase with dashes. This does mean you can't use Javascript dot notation for referencing it. I think handling it like this in Obsidian Linter would be best.

Read more about it here

---

Functionally, it seems to store both values as a list when both frontmatter and inline are given (at least in the DataviewAPI).

E.g. having a document like this:

---
context: foo
---
context:: bar

Results in the following in the DataviewAPI:

- frontmatter:
    - context: foo
- context:
    - foo
    - bar  

Interestingly, capitalising the inline field does not result in the same.
Dataview seems to 'avoid' the conflict, by not returning the inline field's data unless the capitalised key is explicitly called.

Example:

---
context: foo
---
Context:: bar

Results in:

- frontmatter:
    - context: foo
- context:
    - foo
- Context:
    - bar    

[pjkaufman]

My main concern with the spaces is how to handle the identification of keys with spaces in them since I do not see any specs on them.

[fetwar]

@pjkaufman there is a bit of information on how dataview handles sanitising capitals and spaces in the Dataview Documentation - Adding Metadata. Specifically in the "Field names" table and below.

There is also more in the Dataview FAQ, the relevant question is "How do I access fields with spaces in the name?"

[pjkaufman]

I likely just need to use DataView's logic for parsing out keys and values since it looks a little odd with how it works. The table does not explain how keys with spaces work and how it knows a key has spaces in it.

[fetwar]

Oh my bad, I think I mistook your question, potentially this might help.

An inline field needs brackets unless it is on its own line.

If the double colon is detected, this is determined to be a key, if no brackets are surrounding it, the entire line will be parsed as the key value pair.

So these would all be detected correctly as the same thing:

Test Key:: 1234
Some random data in the line that shouldn't be interpreted as a key [Test Key:: 1234]
Some random data in the line that shouldn't be interpreted as a key (Test Key:: 1234)

I am guessing that if someone was to forget the brackets, it would attempt to parse the whole line as a key value pair.

An interesting note is that when within a list item or task list, the values within brackets apply to that line only. Anywhere else in the file applies to the whole file.

I hope this helps, my bad for being a bit misguided in my last response