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 .
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 “”.
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 ” just using [[ 20240603 ]]
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.
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?
After seeing this message on Reddit, I wondered if the topic had been discussed in the community forum and found this thread. I think using front matter (or tags, or raw text) via Obsidian-style DataView functionality would be incredibly useful.
I’ll paste the Reddit post here so you can read it without leaving the community.
Obsidian’s most popular plugin is DataView, which creates dynamic markdown tables (and other things) from note contents using SQL-like queries. I’ve relied on it for organizing my classical composer notes, to summarizing work items, and project tracking.
We don’t have plans for something like Dataview, but generally speaking, we are more interested in understanding what the community’s interest is around a feature request. Then we consider the work required and the downsides of the single request.
If I have to skip to the first part here and assume there’s interest, I’d say the work required is quite huge for implementing something feature-rich like DataView. The first thing that comes to mind is that, right now, notes’ YAML is not migrated to a database level in Bear (a database migration is necessary), and implementing the dynamic tables natively will require us months, if not years. This is considering that Dataview is released under the MIT license, so we can use part of it internally.
Just to clarify - I’m not suggesting integrating the actual Obsidian Dataview OSS component. What I’m thinking is more like simple dynamic data pulling (“Smart Pulls”) that fits Bear’s philosophy. It’s smart tag aggregation or basic frontmatter collection rather than complex tables or formulas. It is obviously still a big undertaking.
Examples of how we’d use it:
Notes tagged #recipe with prep_time: 15min creates a list of easy to cook meals
Workout notes with exercise: frontmatter shows the types of training I do most often
Notes with status: overdue, to show all the things I’ve missed
Right now, Bear users manually maintain these kinds of lists or rely on search. You could argue that search gives you similar results, but search makes you remember queries and dig through results. This would be persistent, update automatically, and offer multiple pulls on one page to show relevant things based on context. Even basic dynamic pulling would eliminate the “find all my X notes and copy the relevant bits” workflow that Bear users do constantly, but Obsidian users usually don’t have to deal with.
The community interest seems real, but I get that the technical lift is massive either way.
@trix180 Why not plugins? I’m not talking about a store or anything that big, but maybe you could isolate what’s needed in the core and rely on third‑party or even community‑developed plugins with Shiny Frog’s approval.
As a clear example (not of code quality), BearClaw — I developed that to add daily notes features as close to Bear as possible. If an improved version of that app is merged and the user chooses to enable it in settings, it would be very nice. Same with front matter — I’m sure someone could develop something like that if you give us some tools on the API side.
Now that we have LaTeX formulas, Bear is a great environment to draft academic assignments/papers that you then export to markdown and render with pandoc via pdflatex. You can use the YAML frontmatter to pass parameters to pandoc like this:
---
author: yourname
bibliography: zotero-exp.bib
csl: harvard-cite-them-right.csl
geometry: a4paper, margin=1in
header-includes:
- \usepackage{fancyhdr}
- \usepackage{amsmath}
- \usepackage{float}
- \usepackage{setspace}
- \pagestyle{fancy}
- \usepackage{titlesec}
- \newcommand{\sectionbreak}{\clearpage}
- \fancyhead[L]{}
- \fancyhead[R]{}
- \fancyfoot[C]{}
- \fancyfoot[R]{Page \thepage}
- \onehalfspacing
subtitle: Will go under your title
title: Title of your paper
toc: true
link-citations: true
---
If plugins are something that can add functionality to the editor, we don’t think it’s a good idea at the design and development level. Making a plugin system for an HTML-based app, such as Obsidian, has different implications than a native app like Bear. There is a middle-ground solution by having web-views inside the editor, loading HTML/JS plugins, but that too has heavy implications on the app memory usage, and that’s a problem on mobile.
I have to admit that there are hypes that also trigger euphoria in me. But once that has worn off, I realize that there are other ways to achieve the same goal. 20 years ago, when I was still in the Windows world, I was an enthusiastic user of foobar2000 and also participated actively in the forum. The clearly formulated wish of the devs was that the users should rather describe in their requests what they want to achieve instead of concrete features and their detailed implementation. I keep coming back to the point that bear sticks to its core concept, the nested tags, and builds new features around them, rather than new layers of organizational tools. Of course, these kinds of features, as notion has popularized them, are useful and exciting. And it may be that I will also use them for certain purposes in the future, for example in Craft or Obsidian. Both apps are free and too good not to be used. Nevertheless, I have to say that I wouldn’t mind seeing such a feature in Panda
Actually, the basics are already included in bear: Instead of prep_time: 15 min you can simply write #prep_time/15 min# and instead of status: overdue you take #status/overdue.
It is undoubtedly a tedious task to enter everything manually in the small search field of the notes list. But then you could work on improving the search. In my opinion, this has been neglected so far. But if I remember correctly, the devs here already hinted a long time ago that the search should be improved. There have already been requests for the search field in the notes list to display an autocomplete field when tags are entered. And I have made a well thought-out suggestion here, for example. In my opinion, there is still a lot of potential as far as the search is concerned.
.
