Indenting lists

Immediate feedback - like the look of the new editor/app. The note list looks good and works well. Like others, I’d prefer to see which heading level I’m on rather than the three lines.

Toggling visible/invisible Markdown might be nice for users like me who are so used to the old style but I imagine I’ll get used to it.

The thing I immediately missed was using Cmd + ] and Cmd + [ to increase/decrease the level of the indented list. Any chance this could be added back - it’s in my muscle memory.

One more question - any reason tags now begin AND END with #?

Thanks - exciting developments.


Looking at Panda, it appears this has been moved to ALT + CMD + [ and ALT + CMD + ]. So it looks like the defaults have changed in Panda and I bet this is the same in Bear 2 as well.

But you can override the shortcuts in macOS and put them back the old way. You’ll want to override Edit → Move Left and Edit → Move Right. (You can use this same technique for most apps for most shortcuts on macOS. It’s great!)

Steps here.

We changed the shortcuts to ⌘⌥ to uniforms with the cell moving shortcuts inside the tables.
You can remap those as @xierox suggested.

We are investigating a possible bug that forces the # even when is not needed.

Thanks for the feedback.

1 Like

These appear to have since been changed again to be Alt + Cmd + [left arrow|right arrow]. This is a disappointing shift (pun intended) and it would be great if the team could consider whether this makes Bear an outlier in behaviour compared to other macOS apps.

The shortcuts Cmd + [ and Cmd + ] are used in nearly every editor application I use regularly (Drafts, Nova, Xcode) for indent/outdent. I understand the desire to use these shortcuts for navigation features (like they are used in browsers) but, for me at least, editing is my primary activity in Bear and not navigation. Maybe y’all have more usage information that contradicts my assumption that people tend to edit more than navigate?

Tab and Shift+Tab will also shift right and left.

I don’t use the three apps that @mrk mentioned. But every app I know of that supports navigation history uses Cmd+[ and Cmd+] to navigate through that history. My fingers would be very confused if they did otherwise. JetBrains editors, every browser, Slack.

@mrk If our Bear overlords don’t make the change you suggested, you can always change the keybindings yourself in System Preferences > Keyboard > Shortcuts > App Shortcuts.



@wmesard I get that, and that’s why I mentioned editor apps. A browser is a different thing from an editor though. And I think what bothers me a little is that (according to this thread) this change originated from a desire to keep consistency with editing behaviour inside tables, not from a desire to have navigation consistent with navigation in other apps.

I do appreciate that I can remap this to suit me personally, but I run Bear on at least 4 different Macs (I have a problem, don’t judge me :wink:) so I have to re-apply these settings every time I fresh install macOS or get a new Mac (it will happen frequently, again don’t judge me :wink:) and doesn’t even address the lack of remapping support for iPad.

Of course, I can’t go back and check Bear 1 now as I’ve migrated my notes to v2 and I’m not inclined to wipe it all down just to check this, but I don’t think I would have noticed this behaviour in v2 if it hadn’t been the standard in v1. Personally I think that’s just as important as lining up apps on either side of the behavioural divide.

1 Like

I do this all the time on the mac, especially in Keynote.

However, Bear’s ignoring global keystroke changes… except when it accepts them.

On my MacBook pro I have indeed mapped command] and command[ to be the normal shift functions. and it works. The menu reflects that.

But on my mini, Shift Right mapped, but there is no way to change Shift Left. It stubbornly refuses to change. So I’ve got one one way and the other not. This also happened on a recently retired iMac.

So some parameter list is not behaving.