So I have a friend who is new to Bear, and we got talking about the presence of Markdown in Bear and I had some realizations that I haven’t been able to voice before when seeing other people complain a bout the syntax highlighting.
Choosing to maintain the Markdown syntax in the Bear note is a major and important design decision that is a huge asset to Bear. It’s not just an asset in that it’s fairly unique, but in how notes handle.
The options
If you look at the ways other Markdown apps handle syntax, there’s really two options. One is to essentially convert any and all Markdown to rich text after it’s clear, and the second is to have different modes that a note can be in (for simplicity’s sake, an ‘editing mode’ and a ‘view mode,’ if you will).
Rich Text-like
In the case of the former, Markdown syntax is basically rendered into formatted rich text in its behavior within its own app. When copying it out, it might copy as Markdown on the clipboard, but editing it is very different from editing the raw Markdown. Apps that behave like this include Agenda and Day One.
When going back to edit text that is already formatted, and wanting to switch between different modes of formatting, I find this behavior often nets undesirable results. For example, if I put my text selector at the end of some bold text to begin typing, the app may or may not make what I type bold. In most regular rich text editors, I would likely have a visual indication on the formatting bar that the ‘bold’ function is either enabled or not, but these visual cues are often absent in the Markdown apps with this behavior. In Bear, though, maintaining the ** characters at all times lets me have clarity as to whether the text I’m adding will be bold or not, depending on whether I put the insertion point inside or outside of the asterisks.
Mode Switching
Then there is the shifting between an ‘editing mode,’ and a ‘view mode.’ In the editing mode, the Markdown is necessarily visible, and in the ‘view mode,’ only the formatted text is, although in the latter mode the text is not editable. This is actually the way Markdown was made to exist (although the ‘view mode’ was in a web browser after parsing Markdown through the renderer). This behavior is achieved in apps like Simplenote and Drafts through their ‘Preview’ function, and with any Markdown text file with an app like Marked. It’s also the behavior of most “dingus” editors, and the Discourse editor itself.
The issue that arises with this method, of course, is that switching modes is clunky. In many of these apps, the syntax highlighting of the Markdown in editing mode is very minimal in comparison to Bear. Most do not do any resizing of the text as Bear does for headers, or any collapsing of text like Bear handles in its links (and in the new beta, footnotes). Some have even fewer features in their editing mode. And Bear already has something of a ‘view mode’ in its export options and integration with Marked.
Conclusions
I understand the desire to remove Markdown syntax from a note. But how could Bear handle it? What do people who actually want it gone want? Before I dig into this, I want to state that I don’t presume everyone asking for it wants the same thing necessarily, but I want to talk through the logic of the desire behind it.
If there’s the desire to have it vanish from a note that is no longer to be edited, it’s there. If it’s to switch between an editable and view mode, then the solution is to pick up Marked, unless the complaint were solely that such a feature were missing on iOS. So I feel what really must be desired is some kind of rich text-like mode.
People often put forth the idea of just making it an option to disable Markdown syntax in a preference pane and keeping the syntax for those that like it. This winds up ignoring, though, that a strong and reasonable implementation of a syntax-less mode would need to exist. This would be a huge undertaking in terms of getting right from a design perspective, and take time and effort away from more worthy endeavors for Bear as a whole. It’s possible that there is no way of getting it right. If there was, I think the great developers of the apps that have this kind of a mode would have found it by now. And even if it was handled well, the modes would likely need to diverge in such a great way that it would create a huge strain on further development.
Obviously I wouldn’t expect the official line from any developer to be “if you want that feature, use another app,” but at the end of the day, the manner in which Bear preserves the Markdown syntax for ease of editing is core to what makes Bear the product it is. I don’t think it’s that those clamoring for something else want another product (mostly), but they aren’t acknowledging the way in which syntax being preserved makes the maintenance of their Markdown notes as smooth as it is. I’ve struggled for an apt comparison, but it’s a bit like complaining that Excel handles certain input as a formula, and that typing an equals sign should handle a string instead. Removing that feature would greatly diminish the primary strength of the application, and in the cases where it’s necessary, there are ways around it (in Excel, an escape character to get to the equals sign; in Bear, exporting or previewing in Marked to remove the syntax for a permanent copy).
Of course this has nothing to do with the features of the Panda beta, but I feel it needs to be voiced. So many people have felt like they’re “not being heard” with this “easy suggestion,” and I think those people are owed an answer, even if it’s not one they like at first glance. I think, though, that understanding this can lead to people either making their peace with Bear’s handling of Markdown, or continuing their journey towards their most optimized workflow – which I firmly think, if they want the best handling of Markdown in their notes, will ultimately lead them back ot Bear.