I would love to reuse YAML defined variables through the note, for example if i define a date: or due-date: or customer: field, having a syntax to reference that value elsewhere in the markdown text, for example in [[:date]] or [[:due-date]] or :customer to avoid repeating myself, avoid mistake of one update not linking to other updates and make templates easier to write.
3 Likes
Oh and the MetaEdit plugin provides a GUI for both front matter and Dataview fields.
1 Like
@tobei You can actually do that already with the Dataview plugin.
Example for filename 2022-02-12 Sat:
---
type: Daily Note
---
`=this.type` was made on `=this.file.name`
Renders as:
Daily Note was made on 2022-02-12 Sat
Downside is it currently doesn’t render the inline queries in live preview, at least on my machine. The normal queries (tables/lists) do render properly in live preview.
https://blacksmithgu.github.io/obsidian-dataview/data-queries/
1 Like
And also that the page on disk contains code and not just the text result so without that plugin or if the plugin stops you are left with just code in your notes unless i’m mistaken?
I think the thread targets improvement that should be made into the core of Obsidian itself, to support natively, and as such my suggestion is something i would like to be officially supported as a feature.
Actually I do see key: value pairs in the front matter as how every tag should be: tags that can have value, simple tags being just keys with no value. As such i should be able to search in the native search box, in the [[ auto-completion list, in the graph view for expression containing those keys or values on those keys. That’s the huge difference between a core-supported native feature and a plugin improving on a core feature.
And because i see all those variables as if they were valued tags i really don’t need tags: and would be totally fine with declaration inline such as #key:value matching the front matter key:value. Value tags are a superset of regular tags, much more useful, and doesn’t need support for two different concepts
Yes the Dataview plugin renders dynamically.
To get the value of YML once and permanently encode it in the note as plain text you can use the tp.frontmatter module from the Templater plugin.
https://silentvoid13.github.io/Templater/internal-functions/internal-modules/frontmatter-module.html
-
But then i guess it won’t sync if i change the frontmatter, so i’m back to repeat my change everywhere. Furthermore if values are not encoded they are also not searchable which impede a lot of native functionalities.
What i suggest is something you can also do in word, have real values in a document but who comes from variable you define just one time, then either they update automatically as you change the variable, or you just right click “update now”. -
My second suggestion is that any key:value is effectively a valued tag, regular tags being just the special case of a tag that didn’t get any valuation. And again, to have that work accross the whole Obsidian, in every view, in every search, in every auto-complete, in the graph views, available within plugins, it has to be core, because only core features can work everywhere.
But then i guess it won’t sync if i change the frontmatter
Well the only way I think to do that is to have the Obsidian app monitor every text character on every change and try to match it to a front matter field and automatically replace it instead of rendering the text dynamically.
The problem would be for the devs to figure out a way to persistently track per-word metadata somehow in a way that persists across not only note viewing sessions but entire Obsidian restarts which seems non-trivial.
My second suggestion is that any key:value is effectively a valued tag
Those aren’t tags and I would disagree with treating them as equivalent to tags because it would mean you are parsing every single colon-delimited pairs as tags which is unexpected behavior. There are lots of reasons to have field: value pairs in a note that have nothing to do with being searchable metadata. Just one example is a playbook note that describes how to work with JSON in an API. It would be filled with field: value pairs that have zero meaning outside that one note.
2 Likes
That’s just a matter of syntax, could be #field:value in text instead, just like #tag is no more a standard in markdown and also kind of conflicting with the header format, and hierarchical tags are not a standard thing either, those are all choices.
As to parsing variable in a whole text, that would only happen when the frontmatter is changed, and the whole thing is already parsed again and again as you type for syntax highlighting and formatting, it is basically what CodeMirror does, and that library is used for syntax auto-completion etc, things far more demanding than markdown.
Anyway, this thread is more about functionalities description that “how to implement them”, those are functionalities that exist in other software and that I find incredibly convenient, and ideas should be discussed on their merit and usefulness and not on how difficult they would be or conflict with a standard that needs to be extended anyway to offer anything more useful that the basics, that’s why markdown gets so many flavors and that so many stuff is already represented as codeblocks. If markdown gets in the way of anything useful, maybe it’s not the right tool for the job, or maybe it needs to be turned upside down 
Doing standard for the sake of doing standard is much less important than having the tool be useful for the user, and that in my opinion is the only thing that matters.
Hey, I would love to add folder: location into YAML. So that iit automatically moves the file created
Support in-content JSON?
I guess YALM is a kind of JSON, except that it doesn’t fully support links (you can use the format key: "[[link]]", but I heard that there is a case that you cannot put links in there. Unfortunately I don’t fully remember the details). In my understanding JSON has more flexibility than YAML? So I just wonder why can’t we use JSON in the middle of the content, like LaTeX or mermaid?
Case 1: list of links
text text:: value
subcategory: {[
[[link 1]],
[[link 2]]
]}
-
I don’t want to put this in the frontmatter, because it’s more natural to have read this list at the bottom. Plus that links aren’t fully supported in there
-
If I use the Dataview inline, i.e.
subcategory:: [[link 1]] [[link 2]], then it will be cluttered if there are many items and the links are long (alias won’t help) -
If I use tasks instead, i.e.
- [ ] [[link 1]] - [ ] [[link 2]]then I can only query them with
file.tasks, not with the actual key I want. The checkbox also gives me false impression. -
If I separate the list in multiple lines, i.e.
subcategory:: [[link 1]] subcategory:: [[link 2]]then the connotation that link 1 and link 2 are relevant will be lost. They are two arrays of one element, not one array of two elements.
Case 2: declare metadata for non-existing files
[[link 1]] : {
key 1: "value 1",
key 2: "value 2"
}
While link 1 hasn’t created yet. This is extremely useful if you are working with graph database. See the Link Types - Juggl
With regard to YAML futures, I don’t envy the design and development dance between the features & user interface desires with the performance impacts. Front matter resides in the app cache where it is parsed and indexed. Now that we use it as a repository for database like meta data, I wonder if there is another structure for our thirsty meta data needs?
5 Likes
A front matter typing assistance, type checking and auto-completion.
Would like to see a plugin where you define type for some front matter value function to key.
It would for instance autocomplete from a defined list
Show an error (red color or something) when the type is wrong (e.g. when entering a string for a number etc … )
4 Likes
I just added a new feature request, so I’m linking it here as well: YAML as Editable Table in liveview
3 Likes
I’m not sure if the devs are still watching this thread…but one idea could be to allow block-level metadata (or inline metadata that applies to the block where they are). The goal would be to enable block queries similar to those enabled by Tana supertags.
3 Likes
I really like the suggestions in this thread but would also love to see something basic added: With the current system, I only have the option to see all metadata or none.
What I would like to do is define what I can see even though metadata iss switched off.
Why?
Because I put my tags into YAML and I also have a lot of other stuff there in many files: csslass info and plugin related stuff.
This latter type of metadata I do NOT want to see in my notes all the time. The tags I DO want to see always.
It would be great to have a toggle that can be put inside the editor that switched betwen two or even three user defined sets of things to display.
2 Likes
While this feature request lives it life, I would like to point out that using CSS, we can hide/show tags, aliases and other frontmatter.
Details given in my post above.
1 Like
Oh!
This is VERY helpful. It’s an elegant, well-working solution. THANK YOU!
1 Like
Borrowing liberally from Metadata Menu, I would love to see YAML classes. Something like this:
yaml_person.md
---
name: {String}
email: {email}
age: {int}
---
That can be loaded into a file dynamically with the built-in template plugin, e.g.
{yaml_person.md}
Becomes:
---
name:
email:
age:
yamlClass: yaml_person
---
Now let’s say I call that new file John add some metadata to it:
---
name: John
email: [email protected]
age: 25
yamlClass: yaml_person
---
It would be cool if, as other mentioned, there was some kind of inline typing going on. E.g. I could say he works at a company, and show an inline list of notes tagged #company, much like we do with Metadata Menu.
Let’s say I then revisit my vault 6 weeks later and decide that all person notes need a birthday. I would update the yaml_person.md file as follows:
---
name: {String}
email: {email}
age: {int}
dob: {date}
---
It would be amazing if Obsidian now cycled through all the notes that had the yaml_person class and added the dob, i.e. John.md becomes:
---
name: John
email: [email protected]
age: 25
dob:
yamlClass: [[yaml_person]]
---
This would save incredible amounts of rework.
If there was then a function to move YAML up or down in the stack, or indent it, you’d be able to restructure your notes on the fly without going back.
You could then probably also do some really great things with inheritance and YAML, where say type: coworker extends yaml_person like so:
yaml_coworker.md
---
company: [[file]]
role: {String}
yamlExtends: [[yaml_person]]
---
And when you hover over [[yamlExtends]], you’d get a preview of {name, email, age}.
So if you were to then change the yamlClass of the note john.md, it would turn into:
---
name: John
email: [email protected]
age: 25
dob:
company: [[acme]]
role: [[design]]
yamlClass: [[yaml_coworker]]
---
4 Likes
Is there any timeline from Obsidian team regarding this?
Interesting concept. This would provide some of the functionality of supertags in Tana 
1 Like