Hello friends, thought I would initiate a thread so we can consolidate our ideas and suggestions to help our dear developers with conceptualisation/ideas for YAML metadata improvements, as shown in the short-term roadmap:
Licat: we haven’t fully defined the scope of the YAML improvements, but I’m thinking, adding some kind of UI to interact with them, adding more API for plugins to make changes to the YAML, possibly look into supporting inline definitions, and lastly supporting more commonly used frontmatter items like links
Basics
YAML is basically that section you put at the top of your page:
---
key: value
key2: value2
---
As opposed to inline metadata which is done like this, with the advantage that it can be inserted anywhere in the document at all, including within text:
key:: value
key2:: value2
An example of it being within text (similar:: value).
How would you like a UI to be designed if there is one for YAML frontmatter?
How would you reconcile inline metadata with YAML frontmatter?
How would you introduce auto-population or automation or variables to metadata?
Would you like the ability to compute frontmatter? For example, taking the values of key and key2 to produce a sum in key3? Concatenation? User-defined functions? Do you think that is possible?
Other suggestions to add to YAML?
How have other applications solved the problem? What can be borrowed?
What kind of support for plugins should there be? (examples: breadcrumbs, pdf annotators, Dataview, etc)
I’ll start with a short request - would love to be able to have dropdown menus or predefined choices for each value on a UI. Also reuseable templates that can be used with different attributes.
Interestingly the Supercharged Links plugin provides a lot of functionality that is asked for. It just does so from the point of view of the link to the note rather than directly editing the frontmatter in the note itself.
In particular it gives you a context menu from a link that pops up a modal where you can view and edit the link’s front matter, and it allows you to define set values for front matter and toggle between them. So you can define a status: field for front matter and give it the values unstarted, started, blocked, completed and then toggle from state to state by right clicking the link to that note.
So it basically lets you define a schema for various front matter fields.
You can also dynamically style the link based on a note’s front matter i.e. add prefixes, suffixes, change color, etc based on what the various front matter fields say, state of certain fields, etc.
This IMO can be a very good initial guide for what a native GUI approach to front matter can provide. There’s a LOT of hidden power in this plugin.
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.
@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.
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
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.
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.
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.
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?
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 … )
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.