That’s the wrong default on macOS given how it violates conventions of how text on that platform. It’s kind of stuff I expect of subpar crossplatform apps forcing Windows conventions upon their users, not of high quality apps that are good Mac-citizins.
I know that this is maybe less used for those with european keyboard layouts, but for me this completely breaks how I use text editing on the Mac. It works on every other proper Mac app. Bear shouldn’t be an exception.
I checked to see what actualy default behavior is in many places.
While it’s not always defined in the menu items, by default:
Command bracket behaviors in various text oriented apps:
Google Docs running in Safari (yes, seriously!)
Mail (only for rich text)
OmniFocus (not really text as such, but still interesting)
Craft (forwards also creates a link and navigates to it, so quite different)
I suppose the lack of this behavior being documented is maybe what made Bear developers overlook it.
I find it very interesting that even in Safari, if you are editing in Google Docs it uses does indent/outdent if you are editing text. And of course it doesn’t indent in Finder, there’s nothing to indent. It’s not a text editor!
The only example I could reproduce that did the navigation insted of shifting while editing text was Craft. And I don’t know, maybe that justifies it considering it’s a Bear competitor.
I’ve indented/outdented using this keyboard shortcut in Bear 1 forever and in many many Mac apps for over a decade. It feels like people pulling the rug underneath you when that’s suddenly gone.
Considering the swatchs of examples I give where if your in a context where mac apps pretty consistently prioritises indent/outdenting if you’re in an active text edit field I think Bear 2 ought to follow this convention. Just like Bear 1 did.
Some apps don’t support tab for indenting (it just inserted the tab character, replacing if something was selected), but that’s pretty rare (at least these days) and I only know of a few which do that now.
TextEdit (in plain text mode)
The convention these days in most apps is to support both the tab/shift-tab key and the command brackets. Bear should follow this convention. This way people used to whatever convention can carry on editing text in Bear th way they’re used to.
Most of those apps that indent with ⌘] are single-page document apps that don’t have a concept of a navigation stack. Although apps like Mail have pretty similar 3-pane UI, you don’t really navigate between emails through links and backlinks, there’s just a concept of going to next/previous mail in the list.
Bear isn’t just a text editor, it’s also an app where you navigate forward and back through links. Kinda like Safari where ⌘[ goes back after you clicked a link. I find it intuitive that Bear navigates back with same shortcut too (although it’s ⌘Ö on Nordic keyboard but I think it’s the same as ⌘[ on US layout).
Your right that there is a conflict between editing and navigation here. I suppose there isn’t a perfect solution here. No matter what default Bear choose I suppose it will break some people’s usage patterns.
Thankfully you can override these (in both directions presumably) with keyboard shortcuts using System Settings.
I just recently used macOS Ventura. I maintain that historically cmd brace really did indent/unindent, and the standard for going back (forward) was cmd (shift) minus, but it really seems like going forward Apple is standardising on cmd brace as navigation in apps.
So I suppose my confusion came from macOS changing from what they traditionally did. I think it’s reasonable for Bear to follow current macOS standards (as much as I might dislike said standard), and thankfully at least you can override it with Bear using custom keyboard shortcuts.