As many of you may know, Panda is the file-based markdown editor that we created to beta-test Bear’s updated editor. While it’s been floating around in beta for a while, we are now looking at making it a standalone product. To make working with multiple markdown documents easier, we’d like to have the markdown editor paired with a folder view, or something similar.
Our overall goal is to keep it as simple and clean as Bear, but also powerful enough to support your use cases. Your feedback is crucial to us and will help us turn Panda into an unstoppable markdown editing machine! So, we need to know what your vision is for Panda. This then leaves us with some important questions.
What kind of content would you work with? How many files would you typically have in a folder? Are markdown extensions such as tags and wikilinks of importance to you, or is strict adherence to plain CommonMark more desirable? Would you use other tools to process the markdown folder, for example, static site generators? Do you plan to store these files in a sync-enabled folder? What features would be must-haves, and how would they help you archive your tasks?
There are so many questions! Let us know what you think.
This comment is coming from using it in an iOS environment. It would be nice for it to have the ability to manipulate the file system (ie. add/edit/delete files and folders). If you gave it the ability to have file/note links and back-links I could easily see it becoming very popular with people making their own note system.
And certainly be able to be in a sync environment (ie. iCloud).
Ability to lock/password protect a file.
I believe there is a lot that could be done here with a simple, yet powerful, file editor.
Regarding the interface, having a tab-based setup would be helpful with behavior similar to the Drafts app where as soon as you open the app it opens to a blank note ready to go without having to do something like create a new note or open an existing one.
Yes, I can see a lot of use cases that I can think of right off plus numerous ones that others will chime in on.
I have a well set up folder structure with a few thousand markdown files. I use this for everything, notes, diaries, plans and a recipe store.
I have one folder with a few thousand notes that are grouped via hashtags. Currently this works well in iA writer. Wikilinks are o.k but not super essential. Quick open is essential, a quick open that looks inside the notes.
These files are stored in iCloud and once gain iA writer handles this flawlessly.
But iA writer is o.k, but there is much I don’t like about it. The typography isn’t all that great, it’s insistence on not hiding markdown I am not in love with. When you’re typing in it, you know you’re in iA writer, which is by intention but you’re always aware of it. It’s native but has somewhow managed to not really fit in to the eco system. This isn’t the case with bear, it’s UI is so polished that it feels a normal extension of the MacOS ui. The file browsing is also done poorly, you can’t see a file tree it has to be a folder by folder access.
There is no wonderful stand-alone Markdown editor on Mac and iOS. Panda would be.
I would be looking, mostly, at using it as a cross-platform Typora replacement: edit standalone MD files with Bear 2’s amazing editor. I would have those files synced, so I would really like if Panda on iOS would integrate with the Files app and/or access its own iCloud Drive directory.
What would be even more amazing:
Bear’s theme and typography options
Allow for images / document inclusion the way Bear does, all within a single file (a .panda file maybe, package including both Markdown and the referenced media). I don’t want to manage media the way Obsidian and every other editor forces me to, with external files. Bear is awesome in that it hides this complexity from the user, I’d like Panda to offer the same, so that it becomes my go-to text editor for short to medium length document production including media (a lightweight Ulysses, to take another comparison)
Allow for Bear interoperability: if Bear is present, allow me to reference my notes with wiki links, aliases and tag autocomplete.
Allow for Bear to import Panda files, and to export back Panda aforementioned package files so that they might move freely from one to the other (an independent file may become a note, while a note may be refined to be shared with someone)
On top of regular Bear export options, include big online platforms such as WordPress for blogging workflows
I like where you are going with this .panda file idea. Being a “package” of markdown and any associated attachments. So Panda could read/write any standard MD file but a .panda file has additional superpowers.
I tell you, the more we brainstorm about this Panda product; it may outsell Bear!
I use bear, zotero and apple notes. The latter one for quick notes which at some time will be deleted anyway and for shopping lists which I am able to share. Bear is my mean for note taking and mainly for writing. Zotero handles my notes related to resources like books, articles and so on.
I would use panda as a library for texts (self written or clipped articles from internet). And would replace my writing here while keeping bear for note taking. In terms of pkm I seem to be a librarian rather than a gardener or architect. While I love the pure nested tags in bear, for the task of creating a library I would like the combination of folders and single tags (means: NO nested tags!).
I think while folders are generally overestimated single tags are underestimated. They are easy: you don’t have to think at all about nesting. For a recipe I just have to set f.e.: #fish#italian#paprika and so on. For a text about politics it is just enough to write: #scholz#bundesregierung#dieselsteuer#proteste#landwirtschaft.
It is not only easy to write. If you implement tag browsing like in zotero you have even an incredible powerful way to search quickly and efficient for notes. Zotero combines two principles to achieve that: 1. All the tags listed in form of a tag box are related to the chosen folder. If you select another folder you get another tag box. 2. A selection of a tag inside the tag box hides all those tag that doesn’t match anymore. That’s a kind of powerful browsing in all directions because there is hierarchy of tags and subtags.
If panda would implement that powerful browsing with single tags resp. folders with the same elegance like the nested tags in bear and if also wiki-/backlinks are included, I think many users could be gained. I definitely wouldn’t hesitate to subscribe to both or to pay a price like things or iaWriter
An Importland and fundamentals decision is: should the files be integrated into the folder tree (like in obsidian) or should the files be separated from the tree in form of a files/notes list (like in bear). I would advocate for latter
If there’s some sort of folder view incorporated, I would like to be able to disable this. What I want out of Panda is what I was getting out of Panda: a simple and elegant Markdown editor, period.
Yes, this is a fundamental decision and there are good arguments for both solutions. It would be good with more input on this. Why would you prefer one over the other?
It may be due to a narrow-mindedness on my part, but i really don’t see any advantages of integrating files in the folderview like in obsidian. The only what comes to my mind is maybe that you have just one pane for browsing instead of two. But as you can see in obsidian: you need then a second pane when you want to show your search results in a meaningful way. I mentioned it in another thread: one of bears killer features is to click on a tag inside a note and you are brought to that tag and its notes list WHILE the note still is present as you just have chosen another context of the note. In obsidian that is not implementable by design.
That is my first argument for bear stylish way: the notes list and the search list are on the same place.
To sum up further advantages of seperating files from folders:
The more files you have inside a folder the higher the probability that you ends with just a list of files withot seeing any folders anymore. In a seperated files list i still have on the left side the full folder view in overview and can quickly change to another folder without closing folders
A seperated files list offers a more powerful presentation of the files: you can sort the files by different criterions (date or name) and you easily can display not only the content of a folder but also of its subfolders (by option). In latter case you even could group the files by folder (like ulysses) before applying the sort inside the groups. That would be possible in panda for the reason that a file has an unique place and cannot appear in more than one folder.
A seperated files list can enrich the display of the files with useful information: the date, a short preview and with the coloured file tag
Nevertheless i am curious to hear those users who think an integrated folder-file-view inside only one pane is better
I’ve been so excited at the prospect of a future Panda that when I first saw this post, I blanked at answering how I would use it! The usefulness seems so self-evident to me, but I think it’s a great idea to be more methodical than just “Yes, please!”
I’ve long needed a standalone Markdown-capable editor and have experimented with numerous apps on both macOS and iOS. And while all had at least something to recommend them, each had one or more issues that prevented me from choosing it.
At the moment, I have settled on BBEdit, despite its skimpy Markdown toolset, and that’s mostly because the rest of it fits way better into the macOS ecosystem. (I’ve mostly given up editing Markdown on iOS, but have iWriter Pro on both platforms in case I need to do something more complicated than simple headers and paragraphs.)
To put it simply, the ideal editor for me would be Bear in text editor app guise, i.e. a full-release Panda, updated with most if not all of Bear 2’s current and planned functionality.
Certain features might not make sense to bring over, like, say, the tag list, which is a note-organizing feature. If Panda is only operating on individual files, then there’s no need for a dedicated tags pane. (You could still include them in your text, of course.)
Instead of (or maybe in addition to) a basic folder browser, I would love to see something like what I use in both BBEdit and Sublime Text (and others) — a Project. It could either be a set of Markdown files (and perhaps their attachments?) in a single bundle, or it could be a separate json (or whatever format) .PandaProject type file that has a list of everything linked together in that project/group. Opening it up in Panda would by default open up a pane showing the project’s files and perhaps other associations. (I’m envisioning exposure triangles next to each file that could show an index of H headers in each file for quick navigation.)
And of course those who don’t need project functionality could ignore that feature.
To summarize:
Yes, please!
Standalone Markdown editor with the beauty, strength, and (most) functionality of Bear 2.
Project-like functionality would be wonderfully helpful for my workflow, and I bet a dream to use.
I use Panda generally as an editor for Markdown files from other tools or contexts. Sometimes these are standalone Markdown files in e.g. a Git project, sometimes they’re files from other apps like iA Writer or Obsidian. The single most common use for me currently, though, is for some of my NotePlan notes.
The use case is: I like NotePlan for daily, weekly, and longer-term planning notes. I use it heavily, but find that its window management, navigation, etc. isn’t ideal for some contexts where I like to quickly open and edit a note independent of NotePlan’s current context, or to keep it open free-floating along side other things. I open the underlying files in Panda for this, and have set up shortcuts to quickly get at a few of the most common ones in this way. It may sound strange but it’s surprisingly useful, and is a great virtue of apps like NotePlan and Obsidian that they naturally support this kind of model: you can use many different apps/editors/tools with the files in their database where appropriate to support any workflow. Panda fits into this world (almost) perfectly.
I’ve raised it previously, but one thing that comes up with this kind of usage is that Panda’s insistence on normalizing indents to exactly one format (IIRC it’s 2-space soft tabs?) is often incompatible with whatever I’m opening. I wish at minimum that it could be globally customized as a preference, but even better would be a per-file setting that was auto-detected on file open but overridable, like in a text editor (TextMate is a good model). This is definitely more complex than Bear, but is necessary for interoperating reasonably in the wider world of arbitrary Markdown files.
I would use Panda to manage my main notes, which are Markdown. Having it be a one time purchase would be key for me, even if it is $50 it would be worth it if it is half as well designed as Bear.
Yes, Panda and Bear normalize lists and block quotes to be two spaces per level, but only locally where you are editing (not the whole file). It does follow the markdown standard and should be correctly understood by any other tool fully compatible with CommonMark. Can you give examples of where and how this is a problem?
Supporting more than one normalization scheme would not be impossible, but would be quite a bit of development work.
For the same reason programmer’s editors care a lot about controlling tab/indent behavior, when working with others – especially in contexts like a Git repository of code – it is important to conform to a style, and not arbitrarily mix in other styles.
Many recent apps which use Markdown files but aren’t simple Markdown renderers (Obsidian, NotePlan, and Logseq are prominent examples) don’t fit your assumptions. They generally don’t use CommonMark (but instead other Markdown dialects, though they interoperate well enough for most content), and they are all more restrictive in their parsing of list indentation. I think they all expect hard tab characters for their real, natively-supported indents, and will render spaces mostly just as space characters at the beginning of a line (and all their list manipulation commands will them misbehave with the differently-indented lines). My greatest experience so far is with NotePlan, and there Panda-indented lists are basically broken and need to be manually re-indented with hard tabs to work. It’s probably a bit different in each app, and it’s worth testing interoperability with several of them, as I suspect being an external editor for these is going to be a common use case for which people would really appreciate Panda. Forcing 2-space tabs seemingly never plays well with them.
Meanwhile in most Git repos where I work with Markdown doc files, etc., 4-space tabs are probably the single most common option (as they are in many, though of course not all, programming settings).
In general I’d love a little setting per-open-file like the tab/indent mode always visible at the bottom of the window in TextMate, VSCode, etc. At minimum having a global preference in the app settings seems critical. Most ideal would be both of these, and an auto-detect heuristic on file open that tries to infer the indent mode based on the first indented list it parses (or the smallest indent pattern seen anywhere in the file), falls back to the global preference if there isn’t one, and can always be easily overridden as needed – again, much like how many programmer’s editors behave with files of all types.
Update: Reviewing more, hard tabs are by far the most common in other tools. (This is distinct from programming where hard tabs are pretty uncommon today, and complex indenting of hard-wrapped hanging lines with exact numbers of spaces is often important to get nice alignment for reading the raw text source. This sometimes happens in hand-written Markdown, but much less than in code.) Just supporting this as a global toggle would be a great improvement and hopefully much simpler than the (still ideal) general model above.
The usefulness seems so self-evident to me, but I think it’s a great idea to be more methodical than just “Yes, please!”