Two plugins that I would personally find helpful, but that would likely never be implemented as part of the core app are:
Calendar View: I have several notes that are better navigated using dates than by scrolling. And it’s not always the most recent notes that are relevant so sorting by date doesn’t work for this use case. (As an aside, I know there was a big feature request discussion on this already and that it won’t be implemented as part of the core app.)
Readwise Sync: I have a Readwise account that stores all my highlights from e-books and articles. I would love for these to be exported as Markdown (a feature Readwise provides) and then to be automatically imported into Bear as Markdown notes with an assigned tag. Repeatedly manually importing them gets tedious very quickly, especially since I’m always adding new e-books and article highlights.
I want to reiterate my broader point here so that it doesn’t get lost in the narrow examples: A plugin system, however restricted, would allow for more user personalization and community contributions.
I’m a long-time Bear user, and I already leverage most of its native features. However, I’m also very excited for Bear 2—as are most of the Bear users—because it introduces several features (collapsible sections, image re-sizing, tables, table of contents, backlinks) that I know will enhance my workflow. I’ve been feeling the lack of these features for a while, and I already utilize these features in other apps.
I mention these new features to highlight my bigger point: I don’t think contorting my workflow to fit within Bear’s existing functionality is always going to be the right answer. Sometimes, it will be. But other times it won’t.
All the features I just mentioned were luckily prioritized by the Bear development team and that makes sense because a lot of users want them as part of their workflow.
However, for functionality that I (and a small subset of users) want in our workflows, but which the Bear development team cannot justify prioritizing, plugins could be a happy middle ground.
As a caveat—and I talk a bit more about this in the interoperability section—I don’t think most of the features I mentioned (with the exception of collapsible sections) would be good candidates for plugins because they change the markdown format in which notes are stored.
The broader point here, to reiterate, is that limiting my workflow to Bear’s current functionality isn’t always the right answer. (Nor is assuming that most Bear users are using Bear incorrectly.)
Plugins in Other Apps
I would like to underscore that you said Vim is “natively capable of most of the plugin functionality”; what you left unsaid is that it’s not natively capable of all the functionality. The YouTube video you linked also has a section on the few plugins that the speaker mentions using himself. And this, again, is the raison d’être of plugins in all the apps I listed: To extend an app’s functionality for a specific scenario for the few users who want it, but to leave it unchanged for the many users who don’t.
I think, by mentioning Vim and linking the talk, you’ve made my point
For what it’s worth, I do think that plugins shouldn’t change the fundamental markdown storage of notes in Bear. But in the hypothetical scenario where Bear has a plugin system, the Bear development team would get to choose what functionality plugins are even allowed to have in the first place. I highly doubt they’d expose so much functionality that a plugin could corrupt notes and damage interoperability and/or note storage.
Shortcuts are great—I’m a fan of the ones Bear already has—as they allow combining Bear’s functionality with that of other apps that have shortcuts along with useful scripting logic. Shortcuts, in my mind, are a great example of the benefits of extensibility.
However, plugins could incorporate new functionality within Bear itself, and, ultimately, having a full set of documented public APIs for plugin (or other integration) development in a proper coding language would allow for much more functionality than Apple Shortcuts can provide.
Interestingly, I imagine the Bear team had to expose some Bear APIs for the Shortcuts integration. I wonder if a very similar approach could be taken with plugins…
Finally, all software requires continued support not just plugins. Utilizing any app in one’s workflow means taking this risk, which is, in part, why interoperability is so important.