YAML front matter uses in bear

A few weeks ago I posted a thread on Reddit asking for some information about referencing front matter properties on notes. After asking @trix180 if there were any plans to implement this feature and if it would be useful to have a list of possible use cases for it he told me that “we don’t have plans regarding YAML at the moment but yes, I’d like to know how people plan to use it.”. So here is my list. Please comment with other uses so maybe this feature might be considered.

  • reference status for a note:

    • meeting note 20240603 with metadata “status: unfinished”
    • other note with backlink to that page and after that the same link as you were referencing a paragraph but instead of # you put : or something to reference the metadata, so the reference will be “20240603 unfinished”. Also think about icons so it would be :x:.
    • This would be useful to track if you have processed/done every item you wrote on that note and you can forget about it.
    • Also, keep in mind I’m not talking about a checkbox or a select input because bidirectional communication would be harder to implement, but it would be very nice.
  • metadata categorization:

    • in that meeting note you could add “generic_date: 2024Q2” so you can find every Q2 note of 2024.
    • you can also add “type: meeting”
  • filters:

    • search for type:meeting generic_date:2024Q2 and get a list.
  • lists/tables:

    • it would be nice if we could create lists based on metadata.
    • If we have a “Project A” I can add a manual list of all meeting notes to keep track of them but there is no way to automate this, so if a generator is added we could simply ask for a list of notes with metadata “project:project_a type:meeting”. Also in case of doing this with tables, we could select which data to show, column1 would be the backlink and column2 could be a metadata field such as “is_done:false” and then show “false” or “:x:”.
  • semi automatic templating:

    • you could use a reserved word to introduce templates, for example, if a note has “template:meeting” the system would search for a predefined folder and a note matching the name “meeting” so at the next note refresh (pressing enter) that template would be applied to that note.
  • customizing bear:

    • I don’t know if you plan to implement sharing notes once the web app is live but if you do… how about using “shareable:false” on a note which you absolutely don’t like to share by accident?
    • you have VERY personal notes? “hide_previews:true” so images can’t render on the notes list
    • in order to automate some of the features on this list you could add another one like “property_to_show_on_backlink:status” so when you reference a note it could show like “20240603 :x:” just using [[ 20240603 ]]


1 Like

I exactly know what you are after. But to be honest, I do not think that such a feature set fits into the minimal approach of bear. After more than two years of use, I now appreciate Bear as an island of tranquillity and believe that a special feature set would change its character in a rather negative way.

Nevertheless for certain user scenarios I am also after such features provided for example by obsidian. Such features are useful and absolutely justified. Therefore I hope that they could be implemented into panda which then could become the more “geeky” app for experienced users that you can still tell at every moment is from Shiny frog.

1 Like

Thank you very much for sharing. I can see your use cases mostly revolve around treating YAML as metadata and using note search/sidebar to make those data meaningful. I don’t like how much this potentially collides with tags or in other words, provides another way of note categorization.

Having user-defined variables work in the search might be tricky but I think we eventually overcome this by adding some syntax (e.g. [type:meeting]). Possibly this might require the YAML properties to be DB cached.

I don’t think having the same functionalities “hidden” behind YAML is good for discoverability and user-friendliness. Also, many might perceive a required YAML frontmatter for those functionalities as unnecessary or unwanted.


The possible applications for yaml frontmatter data are endless. In the video you will see another area of notes and how obsidian is even able to present yaml in a friendlier and less technical way (that alone is a value of its own in regard of writing and reading):

I don’t think that it would collide IF the way in which the user can retrieve the data would offer a useful addition to the tags. By supplement I mean that although it would be quite possible to save some tags (why not for the sake of a more tidy tag tree?), the data from the yaml could be used to realize queries that are not so easy with tags. In this context, take a look at the “cooked” field in the video. It is obvious that for good reasons the data from yaml never ever should appear in the tag tree to avoid feature duplication and therefore the usage should totally be seperated from the feature to write nested tags.

I think that some search syntax like [ingredients:eggplant] would be nice but would not exploit the potential of yaml data by far. Obsidian has implemented that new visual representation of yaml as preparation for the upcoming datacore/dataview feature that will allow inline querying of all data and presentation as tables, cards, boards, calendars combined with filter and sorting fields. That, as far as the visual aspect is concerned, is reminiscent of Notion but doesn’t go that far to become a database-centric application.The notes are still the focus. The “Dataview” then offers a flexible display of the notes, a “super map of content”, so to speak, with many possibilities, as you can see in the following screenshots (taken from notion as datacore is yet not released for obsidian).

Would that be something for bear 3.0 or even better for panda 2.0? :wink:

1 Like