Panda: is tagging searchable for externally created files

I’m a Bear admirer, but not a power user and so I might just be missing something obvious. I’d like to leverage the power of Bear as a reader, searcher, and editor against externally created files. In my case there already exists a directory of markdown files. I understand that Panda is intended to cover that. But isn’t organization and search-ability through tagging one of the critical features of Bear? And it seems that it’s missing from Panda? So is it coming, or is Panda just a text editor that can open external files?

Here’s my use case. I’m managing many markdown files with another tool. These are under version control and stored in github. I’d like any non-technical user that is savvy enough to just do a git pull on the master branch to sync files, to then be able to view, search, and navigate them a la tagging as it’s orchestrated in Bear currently. Is that something that I should expect will be possible?

Panda is the Beta build for the text editor of Bear 2.0.

When Bear 2.0 is released, it will function the same as Bear 1.x does today (i.e. include tagging) but the text editor will be replaced with what you see in Panda.

Panda is for testing purposes only and shouldn’t be used as a stand-alone application.

Hope this helped! :blush:

1 Like

Thanks @ZettleZebra – let me take a guess at how tagging would work with imported markdown files.

  • open pre-existing file with panda, or the Bear 2.0 editor and save as a Bear note.
  • that would store the note in the Bear database of all notes. Also would cloudify it for bear pro.
  • a change to the pre-existing markdown file would then have no effect on the version stored in Bear.
    If that’s how it works, then a user would need to import files one by one. And any other editor or version control would be incompatible with Bear as a wholistic solution in terms of searchability and the tag navigator display. Do I have all that right? That’s all fine. I don’t expect Bear to solve my special edge case problems. But that would determine that I cannot use it in addition to other things like in this case in the real scenario I have markdown files under version control in github. I need to avoid bringing Bear into the picture at all it seems because Bear needs to own the entire lifecycle of every file at all times in order for the core value props of Bear to function.

I expect that this type of co-governance model is not within the scope of possibility for Bear if it wasn’t design to work as such on the backend. But I’ll just describe what I’m thinking to be a bit clearer in case anyone is interested. I think that the inter-document linking, rich media addition options, and most of all the conceptual and technical designs around tagging are fantastic in Bear. I’d love to use it like an IDE for mark down documents. As a software engineer I prefer to keep my working efforts applied within honed, efficient tools that are specialized to exact purposes. So I use a specific IDE for code development and then I try to stay in that paradigm as far as possible when creating documentation. I switch over to Alassian’s Confluence with reluctance because it becomes it’s own form and medium all at once, requiring a complete context switch every time I use it. I can actually do a fair amount of documentation still in git using only markdown and some auto-documentations frameworks like sphinx for python. I can squeeze a lot out of markdown and git, especially with extensible and sanitized frameworks like Architecture Decision Records. It would really free me up to stay in the same context (mark down and git) if the result were slick enough to complete with the final product that you see in a confluence org. I have this kind of crazy idea that the organizational structure of Bear is so elegant in it’s simplicity but complex in the variety that it provides that I could actually push the envelope enough with Bear or something like it. But Bear would need to allow for co-governance of the files.