Feature Request: Bear 2 Plugin System

Beta Panda Feedback
1

A plugin system for Bear 2 would help it realize its full potential (at least in my mind) as a platform for markdown note taking. A lot of the other feature requests in this forum (and future feature requests) that aren’t a high priority for the Bear development team could be implemented as community plugins.

Obsidian has had a lot of success with this platform strategy. I know that the obvious caveat is that Obsidian is more complicated to configure and use than Bear, in part because of the sprawling plugin system. However, I’m confident there’s a middle ground and that Bear could have its own unique plugin system that allows for modest additions to Bear’s functionality while still maintaining user privacy and its uncluttered UI.

Is this something that the Bear development team would consider at all?

(PS: I know there was a previous post on this topic two years ago, but I wanted to float this idea again now that the Bear 2 Beta is out! Congratulations on the release :tada:)

3 Likes
2

Voice of dissent here…I oppose this idea strongly as I think this would detract from development of the core app. I want my sub money to support continued development/improvement of Bear as a focused and fantastic markdown writing app with its own personality, not transforming it into an Obsidian-like. If I wanted that, I would just use Obsidian.

6 Likes
3

A couple of points of clarification regarding my original post:

  1. The feature request isn’t to transform Bear into Obsidian; the feature request is to provide a plugin system in Bear—even one with limited access and functionality—to allow for community contributions.
  2. The very point of a plugin system is that it separates the core app from the add-on plugins. Once a plugin system is in place, it wouldn’t detract from the development of the core app. Furthermore, a plugin system often utilizes existing (or promotes better) abstraction and modularity in the existing APIs.

I’m mostly just curious if the Bear dev team would ever consider this architecture decision. Sometimes a couple of niche plugins can significantly improve an already amazing app :slight_smile:

1 Like
4

Of course, I’m in violent agreement. It’d be nice if others that felt the same way posted about it more (ahem).

Now, I’m curious - from where did your idea of a plugin system that’s separate from the core app originate?

1 Like
5

Almost all of my favorite apps over the years have had a plugin system: Firefox, Chrome, Trello, Anki, VSCode, IntelliJ.

1 Like
6

By listing all those apps, I think you’ve made my point. The existence of plugin systems in a bunch of other apps doesn’t necessarily mean that Bear would benefit from having one.

What couple of niche plugins did you have in mind to justify implementing a plugin system? What role does Bear’s interoperability play? If it’s a few niche plugins, why not a few niche Shortcut actions instead?

What about modifying one’s writing workflow to better use Bear’s native features? Some programs, like Vim (a text editor), are natively capable of most of the plugin functionality. You just have to learn how to use it.

By the way, there is also another issue with plugin ecosystems: continued support. I’ve been following the Obsidian community discussions for a while now. Some plugins and themes go through stages of varying degrees of support. Some have to change ownership; some are abandoned. It’s a shame when someone incorporates a plugin into their workflow only to find out it no longer works and there’s nobody around to fix it.

1 Like
7

LOL, i can almost guarantee this will never happen; few things in life i feel so confident in predicting as the idea that bear will never get a plugin system

8

Plugin Examples

Two plugins that I would personally find helpful, but that would likely never be implemented as part of the core app are:

  1. 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.)
  2. 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.

My Workflow

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 :slight_smile:

Interoperability

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.

Apple Shortcuts

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…

Software Support

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.

2 Likes
9

I hope this goes on the “firm no” pile.

There are lots of editor platforms with hundreds of plug-ins - there is no need to ruin a focused, well designed tool by allowing whoever feels like it to bolt things on.

10

If you want to see what Bear would be like with plugins perhaps you should try NotePlan which is about as close to Bear in look and feel as is possible without being Bear. NotePlan has a plugin system and a calendar view. NotePlan also has a very responsive (and fast) developer and a good community on Discord. Warmly recommended.

That said, I have returned to Bear from NotePlan now that B2 is on its way. I found I didn’t really use the calendar stuff and the plugins add another level of complexity I didn’t feel it added much value in the end.

1 Like
11

I, too, have a need to find notes by date without sorting or scrolling, but my notes contain the date. I put dates in the note and use search. So, a search finds everything by date no matter where it is. Bear’s date-picker makes it easy to add dates to notes and text.

I use Snipd for podcasts. I save a lot of podcast clips. In addition to markdown export, Snipd developed a Bear-specific export in the format you described. So, this feature could be developed by Readwise.

Using the word “most” implies “not all”.

Do you have a specific example where a Shortcut should really be an app feature?

A small team of developers supports Bear. I don’t think a Bear plugin would have a small team of developers supporting it. It would likely have one. A single point of failure. Surely, you can make the same distinction.

13

I have no clue about developing software. So when i talk absolute nonsense please forgive.

Actually i am on the side of those who are against a plugin system for bear: i also do not want to see a second obsidian with a ruined ui where each plugin with its own philosophy creates a mashed experience.

But what about an api which allows to create plugins/components which open in its own window and which doesn’t allow to integrate in the main ui or to add own stuff to notes? It is kind of limited plugins.

I am thinking f.e of a canvas plugin that is called by a simple entry in main menu. Or a plugin that shows a graph of linked notes. and so on. The question is how it would interact with the main ui (f.e. opening notes, adding text to special notes, …)

Disclaimer: i am not interested even in such limited plugins but just wanted to throw that into discussion if that makes sense at all what i have written. I am more interested that the devs put their energy in the further development in bear

14

@tbhargav I know I’m late to this party, but I wanted to put in my “vote” (as though I had one) to your idea (although the devs have not responded to this thread tells me it will never happen). If the core experience is the same when not using plugins, I don’t know why the others are so vehemently opposed to the idea. I am not a heavy plugin user in other apps, but I really appreciate the ones I do use. So, it would be a welcome addition to Bear 2, IMO.

2 Likes
15

The experience shows that it leads to a mess. Even in fb2k, a music player for windows, it ended up in an ui with different parts that has an own philosophy. Although the means to guarantee good quality of plugins (even bans were possible) were rigid, in my opinion it didn’t prevent that users felt attracted by the app for reasons that weren’t the developers one. Depending what kind of program you have, it doesn’t necessarily improves it when making it open source or allowing plugins

1 Like